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ARTIFICIAL  INTELLIGENCE  FOR  U.S.  ARMY  WASTEWATER 
TREATMENT  PLANT  OPERATION  AND  MAINTENANCE 


1  INTRODUCTION 


Background 

Most  wastewater  treatment  plant  (WWTP)  designers,  operators,  and  managers 
believe  that  WWTPs  should  be  designed,  operated,  and  maintained  in  the  simplest  way 
possible.  This  principle  clearly  applies  to  U.S.  Army-owned  and  -operated  WWTPs,  where 
poor  efficiencies  sometimes  occur  due  to  a  shortage  of  operators  and  lack  of  training. 

In  recent  years,  it  has  been  shown  that  computer  systems  can  make  WWTP  opera¬ 
tion  and  maintenance  (O&M)  easier  and  less  costly.  Many  persons  in  the  field  now  be¬ 
lieve  that  the  computer  will  be  a  necessary  part  of  plant  O&M  in  the  very  near  future 
and  that  the  computers  will  simplify,  rather  than  complicate,  the  process. 

Installations  are  required  to  comp. y  with  provisions  of  their  National  Pollutant  Dis¬ 
charge  Elimination  System  (NPDES)  permits.'  However,  the  General  Accounting  Office 
(GAO)  reported  in  1984  that  a  significant  number  of  Department  of  Defense  (DOD)  plants 
were  failing  to  operate  within  NPDES  limitations. 2  In  response  to  the  various  problems 
with  Army  WWTP  operations,  the  Army  Operators'  Assistance  Program  (OAP)  was  imple¬ 
mented.  Despite  this  action,  there  is  still  a  need  to  improve  WWTP  O&M  at  military 
installations. 

Artificial  intelligence  (AI)  is  a  promising  technology  in  terms  of  addressing  the 
inevitable  automation  of  WWTPs  as  weil  as  the  need  for  better  O&M.  The  term  "AI"  has 
been  used  in  computer  science  to  indicate  the  study  of  ideas  that  enable  computers  to  be 
"intelligent."  Expert  systems,  a  branch  of  AI,  attempt  to  simulate  human  reasoning  by 
chaining  together  the  important  facts  in  a  given  domain  to  arrive  at  conclusions  logic¬ 
ally.  Recent  research  into  Al/expert  systems  (ES)  has  seen  much  success  in  areas  such  as 
medical  diagnosis,  mineral  prospecting,  and  chemical  structure  elucidation.  A  concerted 
effort  is  underway  to  exploit  this  new  technology  and  extend  it  to  applications  for  which 
human  expertise  is  expensive  or  in  short  supply.  The  application  of  AI/ES  may  provide 
the  Army  with  an  innovative  problem-solving  tool  to  enhance  and  extend  the  limited  per¬ 
sonnel  and  budgetary  resources  for  WWTP  O&M.  Therefore,  the  Army  needs  to  evaluate 
the  feasibility  of  applying  AI/ES  to  WWTP  O&M. 


Objective 

The  twofold  objective  of  this  research  is  to  (1)  identify  and  evaluate  potential  op¬ 
portunities  for  the  Army  to  exploit  recent  advances  in  AI  to  improve  the  performance  of 
its  water  and  wastewater  treatment  facilities  and  (2)  provide  a  general  orientation  to 
this  emerging  technology  for  Army  installations  that  may  be  required  to  assess  its  value 
to  their  WWTP. 


‘Army  Regulation  (AR)  200-1,  Environmental  Protection  and  Enhancement  (Head¬ 
quarters,  Department  of  the  Army,  1982). 

2General  Accounting  Office,  DOD  Can  Make  Further  Progress  in  Controlling  Pollution 
From  Its  Sewage  Treatment  Plants,  GAO/NSIAD-84-5  (February  1984). 
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Approach 

Several  alternative  approaches  were  considered  for  surveying  and  analyzing  the 
potential  of  using  Al/expert  systems  in  Army  WWTP  0<5cM.  From  these  alternatives, 
three  different  approaches  were  adopted: 

1.  LISP  Machine,  Inc.,  Los  Angeles,  CA,  was  contracted  to  analyze  the  potential 
from  an  expert  systems  manufacturer's  viewpoint. 

2.  A  Stanford  University  research  team  developed  a  proof  of  concept  by  construct¬ 
ing  and  testing  an  expert  system. 

3.  Dr.  S.  P.  Shelton,  University  of  New  Mexico,  looking  toward  the  future,  pre¬ 
dicted  how  the  expert  system  would  evolve  and  assessed  the  cost/benefit  aspect. 

Information  from  these  sources  was  analyzed  for  Army  relevance. 


Scope 


This  study  is  limited  to  an  assessment  of  AI/ES  that  could  potentially  be  applied  to 
O&M  at  Army  WWTPs.  The  proof-of-coneept  exercise  performed  by  Stanford  University 
focused  only  on  an  isolated  part  of  the  WWTP  process  and  by  no  means  is  intended  to  be  a 
prototype  system  for  the  Army;  the  point  of  the  exercise  was  only  to  show  feasibility  of 
using  AI  technology  in  WWTP  O&M. 


Mode  of  Technology  Transfer 

It  is  recommended  that  information  from  this  study  be  incorporated  into  Technical 
Manual  (TM)  5-665,  Operation  and  Maintenance  of  Domestic  and  Industrial  Wastewater 
Systems  (January  1982)  and  TM  5-814-3,  Domestic  Wastewater  Treatment  (November 
1978). 


i 


6 


2  ARMY  WASTEWATER  TREATMENT  PLANTS  (WWTP) 
AND  ARTIFICIAL  INTELLIGENCE  (Ai) 


Army  WWTP 

Results  of  a  1980  in-house  Department  of  the  Army  (DA)  WWTP  survey  indicated 
that  the  major  problem  with  O&M  at  Army  WWTPs  was  a  shortage  of  operators  and  lack 
of  training.  In  1984,  GAO  found  that  most  randomly  sampled  DOD  WWTPs  had  not  con¬ 
sistently  met  the  effluent  quality  limitations  imposed  by  their  NPDES  permits.  This  situ¬ 
ation  was  due  to  inadequate  staffing,  a  lack  of  specific  guidance  on  adequate  operation, 
maintenance,  and  compliance,  and  a  poor  maintenance  program.  In  response  to  various 
problems  with  the  Army  WWTP  operation,  DA  initiated  the  OAP  through  the  former 
Facilities  Engineering  Support  Agency  (FESA)  and  WWTP  performance  improved.  How¬ 
ever,  there  is  a  need  for  additional  improvements. 

One  area  still  needing  attention  is  the  effluent  quality  mandated  by  NPDES  per¬ 
mits.  Typical  secondary  treatment  plant  effluent  limitations  that  WWTPs  should  meet 
are: 

•  BOD  and  suspended  solids  (SS):  30  mg/L  for  a  30-day  average  and  45  mg/L  for  a 
7-day  average 

•  Percentage  efficiency:  more  than  an  85  percent  removal  of  influent  BOD  and 
SS  for  a  30-day  average. 

More  stringent  mandates  or  other  limitations  such  as  pH,  fecal  coliform,  settleable  sol¬ 
ids,  residual  chlorine,  total  Kjeldahi  nitrogen  (TKN),  ammonia,  and  phosphorus  levels  may 
be  required,  depending  on  the  receiving  water  quality.  Some  WWTPs  are  still  not 
meeting  these  requirements. 

The  major  areas  of  concern  that  could  potentially  be  addressed  through  AI  applica¬ 
tion  to  WWTP  O&M  are: 

•  Operator  training 

•  Proper  operation  and  control  techniques  to  meet  NPDES  permit  limitations 

•  Efficient  operation  to  minimize  the  operating  costs  (i.e.,  manpower,  energy,  and 
chemicals) 

•  Plant  operation  and  laboratory  records  management 

•  Reporting  as  required  by  in-house  management  and  the  regulatory  agencies 

•  Preventive  and  scheduled  maintenance  programs 

•  Process  control 

•  Corrective  maintenance  and  troubleshooting 

•  Planning,  scheduling,  and  budgeting. 


7 


Automation  and  Computerization  of  WWTPs 

Automation  is  not  a  new  subject  for  WWTP  designers  and  operators.  Proceedings  of 
an  International  Association  on  Water  Pollution  Research  and  Control  workshop3  and  an 
American  Water  Works  Association  (AWWA)  management  resource  book4  summarize  the 
current  status  of  automation  and  instrumentation  for  WWTPs  and  water  plants.  In  these 
references,  many  workers  reported  that  computerization  of  WWTPs  and  water  plants  had 
saved  operating  costs  through  increased  performance  efficiency  and  optimal  use  of 
energy  and  chemicals.  Areas  in  which  automation  and  computerization  proved  to  be  effi¬ 
cient  and  reliable  include:  WWTP  process  control,  information  management,  monitoring, 
water  plant  unit  process  operation,  pumping  station  operation,  wastewater  disinfection, 
plant  energy  optimization,  water  distribution  optimization,  and  maintenance  manage¬ 
ment.  No  water  plants  or  WWTPs  are  currently  operated  by  an  expert  system,  but  some 
workers  use  an  expert  system-based  technique.5  In  1980,  Kelley6  stated  that  the  com¬ 
puter  could  not  be  justified  for  water  plants  smaller  than  20  mgd.  In  1986,  Poon  et  al., 
concluded  that  the  adoption  of  a  microcomputer-based  O&M  system  would  be  beneficial 
for  new  or  larger  (4-mgd  or  more)  water  plants  and  WWTPs.7 

Instrumentation  is  an  important  part  of  WWTP  automation  and  computerization  be¬ 
cause  adequate  monitoring  a^id  process  control  are  not  possible  without  it.  One  of  the 
most  important  features  of  instrumentation  is  the  sensor;  sensing  devices  are  e>'en  more 
critical  when  automation  or  AI/ES  is  implemented.  Some  sensors  are  readily  available 
and  reliable,  while  others  are  not.  Table  1  summarizes  the  current  state  of  the  art  in 
sensors. 


Artificial  Intelligence  and  Expert  Systems 

Al-based  expert  systems  are  computer  programs  in  which  logical  reasoning  is  sup¬ 
plemented  by  theoretical  :'r.o',,!r'1g'\  j"dgmer\t,  and  mips  th-tr^h.  Expert  systems  solve 
problems  that  generally  fall  into  one  of  the  following  categories:  interpretation,  predic¬ 
tion,  diagnosis,  debugging,  design,  planning,  monitoring,  repair,  instruciion  and  control. 

History 

In  the  late  1960s,  early  AI  researchers  believed  that  a  few  laws  of  reasoning  nr>u- 
pled  with  powerful  computers  would  produce  expert,  superhuman  performance.  As 
experience  accrued,  research  began  to  focus  on  narrowly  defined  applications.  From  the 


3R.  Drake  (Ed.),  Instrumentation  and  Control  of  Water  and  Wastewater  Treatment  and 
Transport  Systems  (Pergamon,  1985). 

“American  Water  Works  Association  (AWWA),  Computer-Based  Automation  in  Water 
Systems  (1980). 

5D.  Johnston,  "Diagnosis  of  Wastewater  Treatment  Processes,"  Proceedings,  Specialty 
Conference  on  Computer  Applications  and  Water  Resources  (American  Society  of 
Chemical  Engineers  [ASCE],  June  1985). 

6 AWWA,  p  12. 

7C.  P.  C.  Poon,  et  al.,  Evaluation  of  Microcomputer-Based  Operation  and  Maintenance 
Management  Systems  for  Army  Water/Wastewater  Treatment  Plant  Operation, 
Technical  Report  N-8618/ADA171992  (U.S.  .Army  Construction  Engineering  Reseat,. 
Laboratory  [USA-CERLJ,  July  1986). 
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Table  1 


Important  Variables  and  Availability  of  Sensing  Equipment* 


Area  of  Application 


Variable 


Equipment 

Availability** 


Water  quality  monitoring  Chlorine  residual  2 

iron  3 

Manganese  3 

Aluminum  3 

Heavy  metals  (Cu,  Cd,  Hg,  etc.)  3 

Turbidity  1 

Color  2 

Organic  matter  2 

(UV  absorption)  2 

Taste 
Odor 

Toxic  organics  3 

Treatability  3 

Ammonia  2 

Nitrate  ion  2 

Sewerage  systems  Liquid  flow  3 

Liquid  level  2 

Liquid  pressure  2 

Treatability  3 

Toxicity  3 

Gases  Flow/pressure  1 

Dissolved  oxvgen  2 

Hydrogen  sulfide  2 

Methane  2 

Carbon  monoxide  2 

Carbon  dioxide  2 

Sewage  treatment  Liquid  flow  2 

Liquid  level  2 

Sludge  blanket  level  2 

Sewage  (suspended  solids)  3 

Mixed  liquor  (suspended  solids)  2 

Returned  sludge 

(suspended  solids)  2 

Surplus  sludge 

(suspended  solids)  2 

Dissolved  oxygen  1 

Treatability/toxicity  3 

Oxygen  1 

Flow  (sludge  gases)  2 

Pressure  (sludge  gases)  2 

Calorific  value  (sludge  gases)  2 

Methane  (sludge  gases)  2 

Carbon  monoxide  (sludge  gases)  2 

Carbon  dioxide  (sludge  gases)  2 

Oxygen  (sludge  gases)  2 

BOD  3 

pH  1 

Fecal  coliform  3 

Ammonia  2 
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Table  1  (Cont'd) 


.-urea  of  Application 


Variable 


Equipment 

Availability** 


River  management  Flow  1  <5:  2 

Level  1  &  2 

Temperature  1 

Dissolved  oxygen  1 

Ammonia  2 

Nitrate  ion  2 

Chloride  ion  2 

Conductivity  1 

Heavy  metals  3 

Trace  organics  3 

Biologically  based  sensors  3 


•Source:  R.  Drake  (Ed.),  Instrumentation  and  Control  of  Water  and  Wastewater 

Treatment  and  Transport  Systems  (Pergamon,  1985).  Used  with  permission. 
••Availability  code:  (1)  readily  available;  (2)  sensors  available,  not  necessarily  in  a  form 
suitable  for  the  application  — therefore,  the  system  requires  development;  (3)  in 
experimental  or  prototype  stage. 


mid-1970s  through  the  early  1980s,  work  in  the  expert  systems  field  achieved  much 
success,  examples  of  which  include:’ 

•  PROSPECTOR  has  discovered  a  molybdenum  deposit  for  which  the  ultimate 
value  will  probably  exceed  $1  billion. 

•  R1  configures  customer  requests  for  VAX  computer  systems  at  Digital  Equip¬ 
ment  Corporation,  despite  the  fact  that  even  the  resident  experts  thought  it 
could  not  be  done. 

•  DF.NDRAE,  which  years  ago  demonstrated  superhuman  performance,  supports 
hundreds  of  international  users  daily  in  chemical  structure  elucidation. 

•  CADUCEUS  embodies  substantial  knowledge  of  internal  medicine  3nd  has  cor¬ 
rectly  diagnosed  complex  test  cases  that  had  stymied  human  experts. 

•  PUFF  has  integrated  knowledge  of  pulmonary  function  disease  with  a  previously 
developed  domain-independent  expert  system  for  diagnostic  consultations  and 
now  provides  expert  analyses  at  a  California  medical  center. 


"F.  Hayes-Roth,  D.  Waterman,  and  D.  Lenat,  "An  Overview  of  Expert  Systems,"  Building 
Expert  Systems  (Addison-Wesley,  1983). 
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Basic  Concepts  of  an  Expert  System 

The  architecture  of  an  expert  system  contains  two  fundamental  components:  the 
knowledge  base  and  the  inference  engine.  Figure  1  shows  the  components  of  a  complete 
expert  system. 

The  knowledge  base--the  foundation  of  an  expert  sy:;tem--is  where  the  information 
required  to  emulate  human  expertise  is  stored.  It  differs  from  a  database  because  the 
nature  of  human  knowledge  about  a  domain  of  expertise  is  not  purely  factual.  Real- 
world  knowledge  is  a  much  more  subtle  collection  of  rules,  procedures,  and  relationships, 
as  well  as  simpler  facts  or  assertions,  which  must  be  represented  and  structured  in  such  a 
way  that  it  can  be  conveniently  stored  in  computer  memory  and  accessed  by  the  infer¬ 
ence  engine. 

A  key  step  in  Al  research  was  the  insight  lhai  a  vital  part  of  this  knowledge  is  em¬ 
bodied  in  "heuristics"— that  is,  practical  working  rules  rather  than  theoretical  models 
learned  from  experience  and,  often  to  some  extent,  beyond  conscious  recall.  These  heur¬ 
istics  guide  the  human  expert  to  select  correct  solutions  quickly  and  efficiently  among  a 
multitude  of  alternatives. 


Knowledge  6no 

engineer  user 


Figure  1.  Architecture  of  an  expert  system. 
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Identifying  and  representing  the  heuristics  are  major  parts  of  developing  a  knowl¬ 
edge  base;  this  task  is  one  of  the  main  factors  determining  if  the  development  of  an  ex¬ 
pert  system  is  easy,  difficult,  or  infeasible.  Key  considerations  are  that  the  systems 
must  be  restricted  to  a  limited,  clearly  defined  knowledge  domain,  and  that  the  heuristic 
knowledge  must  be  available  in  some  form— either  from  a  human  expert  or  documenta¬ 
tion. 


The  function  of  the  second  major  expert  system  component,  the  inference  engine, 
is  to  operate  on  the  knowledge  base  and  apply  the  laws  of  logical  inference  to  make  fur¬ 
ther  deductions  about  the  situation  it  describes.  An  inference  engine,  separated  from  the 
knowledge  base,  represents  the  abstract  rules  of  logic  that  ideally  are  independent  of  any 
specific  knowledge  domain.  In  practice,  however,  knowledge  bases  frequently  contain 
procedural  information  that  guides  the  inference  engine  through  the  knowledge  base,  thus 
saving  research  time.  Such  information  is  sometimes  called  "metaknowledge,"  or  know¬ 
ledge  about  the  knowledge  itself. 

Compare  this  structure  with  a  conventional  algorithmic  program  working  against  a 
database.  The  program  is  a  fixed  representation  of  actions  that  should  be  taken  in  its 
domain,  depending  on  alternative  facts  provided.  Although  the  facts  in  the  database  may 
vary,  the  domain  knowledge  in  the  program  cannot  be  changed  without  reprogramming. 
In  an  expert  system,  new  rules  and  procedures  can  be  added  to  the  knowledge  base  as  re¬ 
quired,  and  each  updating  of  the  knowledge  base  can  create  the  equivalent  of  a  new  algo¬ 
rithmic  program. 

Besides  the  knowledge  base  and  inference  engine,  the  other  essential  elements  in  an 
expert  structure  are  the  interfaces  that  link  these  two  components  to  the  outside  world, 
generally  to  a  human  user  at  present,  but  increasingly  in  the  future  to  other  computer 
programs  and  conventional  databases.  A  frequent  requirement,  sometimes  regarded  as 
an  essential  feature  of  the  expert  systems,  is  an  explanation  facility  that  can  trace  the 
line  of  reasoning  a  system  has  used  to  reach  a  conclusion  and  present  it  to  the  user  in  an 
understandable  form. 

The  expert  system's  architecture  also  dictates  the  nature  of  the  tasks  to  be  carried 
out  by  the  users  and  the  talents  they  need.  The  architecture  is  successful  because  it 
places  the  emphasis  of  new  systems  development  on  the  acquisition  and  organization  of 
domain  knowledge.  This  condition,  in  turn,  has  created  the  need  for  "knowledge  engi¬ 
neers"  who  have  the  ability,  training,  and  experience  to  elicit  knowledge  from  domain 
experts  and  structure  it  appropriately  in  the  knowledge  base,  designing  the  who!,  system 
so  that  it  can  arrive  at  required  solutions  quickly  and  effectively.  Thus,  the  whole  tech¬ 
nology  can  be  seen  as  a  means  of  increasing  the  leverage  that  skilled  persons  can  apply  to 
solve  problems  using  computer-based  solutions. 


Example  of  a  Commercial  Expert  System 

As  an  example  of  the  type  of  expert  system  currently  available  on  the  market,  the 
PICON  system  is  described  here  based  on  literature  from  the  manufacturer.  Los  Ange¬ 
les-based  LISP  Machine,  Inc.  (LM1),  is  a  supplier  for  the  PICON  system,  an  integrated 
hardware/software  environm  nt  built  for  industrial  process  management  using  A1  tech¬ 
nology.  The  hardware/software  implementation  of  this  system  requires: 

•  An  intelligent  computer  interface  to  acquire  data  from  sensors  and  actuators  of 
the  physical  process  as  required  for  making  decisions. 
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•  A  technique  to  process  incoming  data  so  that  it  is  directly  usable  for  decision 
making. 

•  A  way  to  enter  the  expert's  knowledge  into  the  computer’s  knowledge  base  by 
the  domain  expert  with  no  AI  background. 

•  A  way  to  access  expert  advice  and  explanations  by  the  process  or  factory 
operator. 

•  An  inference  engine  capable  of  processing  large,  complex  problems,  applying 
expert  knowledge  to  real-time  data  and  responding  in  a  matter  of  seconds. 

System  Features 

According  to  LMI,  for  real-time  response  to  the  thousands  of  dynamic  data  points 
of  a  large  real-time  system,  PICON  is  designed  with  unique  features,  including:  online 
data  collection;  scanning;  focus;  scheduling;  long-term  strategy;  background  mainte¬ 
nance;  and  simulation.  These  capabilities  are  summarized  below. 

Online  Data  Collection.  PICON  interfaces  directly  to  the  process  control  data  via 
its  RTIME  interface  module,  it  selectively  accesses  the  data  needed  for  inference  and 
decision-making.  All  data  is  then  stamped  and  carries  a  user-selected  currency  interval 
that  defines  the  life  of  data. 

Scanning.  PICON  can  scan  certain  conditions  at  regular  intervals  to  look  for  incip¬ 
ient  upsets,  problems,  or  significant  events.  The  user  can  specify  a  scan  rate  for  the 
rules  that  control  this  activity. 

Focus.  Some  sensors  need  to  be  read,  and  some  rules  tested,  only  when  a  certain 
situation  has  occurred.  These  secondary  rule-frames  are  activated  by  the  primary  alert¬ 
ing  rules,  causing  PICON  to  focus  on  parts  of  the  process  related  to  the  actual  or  devel¬ 
oping  problem  detected  by  the  primary  rules. 

Scheduling.  At  the  heart  of  the  PICON  inference  engine  is  the  scheduler.  Online 
applications  require  that  data  be  obtained  from  other  control  or  automation  systems,  but 
it  may  not  arrive  in  time  for  a  particular  inference.  PICON's  scheduler  is  responsible 
for:  (1)  interrupting  and  resuming  inferences  and  actions  that  are  not  complete  due  to  a 
lack  of  data;  (2)  taking  alternative  actions  when  an  inference  does  not  complete  in  a  rea¬ 
sonable  amount  of  time;  and  (3)  keeping  many  activities  going  without  ambiguity.  It  can 
schedule  any  number  of  activities,  such  as  testing  a  rule,  to  occur  on  a  regular,  cyclic  ba¬ 
sis.  It  can  also  schedule  any  activity  to  occur  at  some  specific  time  in  the  future, 
whether  in  3  seconds  or  3  weeks. 

Long-Term  Strategy.  An  expert  system  that  could  respond  only  to  a  current  situa¬ 
tion  would  be  of  limited  utility  in  most  applications.  PICON  is  designed  to  deal  effec¬ 
tively  with  the  rates  of  change,  and  any  abnormal  trends  in  the  process. 

Background  Maintenance.  Because  of  PICON's  large  LMI  Lambda/Plus  LISP 
Machine  and  unique  scheduling  facility,  many  thousands  of  activities  can  be  scheduled  in 
the  background  without  interfering  with  the  system's  ability  to  focus  on  the  current  sit¬ 
uation.  These  activities  may  include  routine  inspection  of  sensors  or  other  pieces  of 
equipment  to  detect  failures  or  marginal  performance. 
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Simulation.  PICON  is  supplied  with  a  dynamic  simulator  that  has  the  same  user 
interface  as  the  knowledge-base  editor.  The  simulator  is  a  distinct  module  that  supplies 
sensor  values  to  the  inference  engine  as  if  they  were  obtained  from  a  real  plant.  The 
user  can  select  the  source,  i.e.,  simulation  or  real  process,  from  which  PICON  captures 
its  data.  The  simulation  can  be  developed  and  tested  incrementally  as  the  knowledge 
base  is  being  built,  making  it  an  ideal  tool  for  testing  the  knowledge  base  and  checking 
PICON's  response  to  both  normal  and  abnormal  conditions.  The  simulator  is  also  very 
useful  for  training  operators,  as  it  can  be  used  to  expose  them  to  situations  seldom 
encountered. 

Interface  Program 

PICON  interfaces  with  a  real  -time  data  source  such  as  a  process  control  system  for 
real-time  data  acquisition  via  the  RTIME  interface.  RT1ME  consists  of  three  functional 
submodules: 

1.  LISP  Communicator  Module:  provides  efficient,  effective  communication 
between  the  programs  that  run  in  the  LISP  and  RTIME  processors.  All  LISP  communica¬ 
tion,  including  shared  memory  used  for  storage  and  access  to  data  in  engineering  units,  is 
invisible  to  the  user.  The  user  interface  is  a  user-friendly,  icon-based  screen  operated 
with  a  mouse. 

2.  Execution  Module:  where  RTIME  performs  all  of  the  preprocessing  functions 
called  by  the  user  as  a  part  of  the  node  descriptor  table.  A  "node"  is  a  designated  data 
source  in  a  process  or  a  plant  network.  RTIME  is  enriched  with  a  library  of  commonly 
used  algorithms.  Specialized  algorithms  can  be  added  to  this  library  to  suit  a  problem 
domain. 


3.  I/O  Driver:  the  element  of  RTIME  that  inputs  and  outputs  data  on  the  inter¬ 
connect  device  chosen  to  communicate  with  the  external  system.  Standard  communica¬ 
tions  are  via  Multibus,  high-speed  RS232,  Ethernet,  and  other  Multibus-compatible  inter¬ 
faces.  Since  PICON  is  applicable  to  a  variety  of  data-acquisiticn  systems  with  differing 
protocols,  it  is  often  necessary  to  customize  this  part  of  RTIME  to  a  specific  network. 

PICON  can  send  expert  advice  to  the  operator  and/or  the  process  to  change  a  pro¬ 
cess  variable  (e.g.,  controller  setpoint  in  a  closed-loop  situation).  The  system  is  designed 
to  be  compatible  with  existing  color  displays  commonly  offered  by  process  control  ven¬ 
dors  to  display  PICON  decisions  on  these  terminals. 

The  explanation  facility  in  PICON  allows  a  user  to  ask  the  system  to  explain  its 
decision  process.  This  information  is  presented  to  the  user  graphically  in  the  form  of  a 
decision  tree,  which  the  system  creates  dynamically  for  every  situation.  LMI  also  claims 
that  modifications  and  additions  can  be  made  to  the  knowledge  base  without  stopping 
PICON. 

Drawbacks  With  Direct  Application 

Although  PICON  is  considered  to  be  state-of-the-art  in  the  AI  industry,  it  is  appar¬ 
ent  that,  at  this  time,  LMI  has  little  experience  with  wastewater  treatment  and  the 
nuances  associated  with  biological  kinetics  and  related  complexities.  Oversights  of  this 
type  are  common  among  those  who  have  had  extensive  experience  in  developing  opera¬ 
tional  control  systems  for  the  chemical  industry  and  seek  to  transfer  that  expertise  to 
biological  wastewater  treatment.  However,  it  has  often  been  found  that  the  heterogen¬ 
eity  of  biological  systems  is  such  that  the  required  complexity  of  control  far  exceeds  the 
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expectations  of  those  who  normally  deal  with  pure  chemical  systems.  This  criticism 
should  not  be  inferred  as  an  effort  to  denigrate  information  from  uMI.  Certainly  the  LMI 
approach  would  offer  a  substantial  foundation  from  which  an  AI  system  could  be  devel¬ 
oped  for  application  to  Army  wastewater  treatment  process  control  and  management; 
however,  it  should  be  recognized  that  the  off-the-shelf  transference  of  current  LMI  pro¬ 
ducts  is  not  the  panacea  that  one  might  perceive  from  reading  the  manufacturer's  litera¬ 
ture. 
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3  FEASIBILITY  OF  AI  APPLICATION  TO  ARMY  WWTP 


Application  of  AI  has  potential  as  an  innovative  problem-solving  tool  that  could 
optimize  the  Army's  limited  resources  for  WWTP  O&M.  However,  it  must  be  understood 
that  the  AI  approach  for  improving  O&M  will  not  replace  human  activity,  but  will  provide 
a  higher  level  of  human-machine  interface.  AI  application  to  O&M  at  Army  WWTPs 
could  possibly  evolve  in  four  different  phases  as  summarized  below: 

1.  The  first  phase  would  produce  technology  analogous  to  an  unabridged  dictionary 
on  WWTP  O&M.  The  information  would  apply  to  all  WWTPs  and,  therefore,  contain  far 
more  data  than  is  needed  for  a  particular  plant  operation.  The  operator  would  query  the 
knowledge  base  through  a  sequence  of  keywords  or  topics  and  receive,  in  return,  infor¬ 
mation  regarding  characteristics  of  the  unit  operation  that  is  experiencing  difficulty. 
There  would  be  no  feedforward  or  feedback  chaining  between  a  computer  and  a  plant  in 
operation.  Therefore,  the  operator  would  have  to  rely  on  self-generated  plant  operation 
and  laboratory  data  relative  to  plant  performance. 

2.  The  second  phase  in  this  evolution  would  be  to  tailor  the  first-phase  expert  sys¬ 
tem  on  a  plant-by-plant  basis.  In  this  way,  a  more  succinct  knowledge  base  could  be 
developed  and  the  complexity  of  searching  efforts  for  a  specific  problem  will  be  low¬ 
ered.  As  with  the  first-phase  expert  system,  this  system  would  have  no  direct  interface 
with  the  operations  and  would  simply  act  as  an  inquiry  system  using  operator-supplied 
data. 


3.  The  third  phase  would  produce  a  recognition  system.  The  term  "recognition"  is 
used  in  reference  to  an  AI  system's  recognizing  a  problem  and  defining  the  problem  vari¬ 
ables  for  future  action.  In  WWTP  process  control,  the  role  of  recognition  is  shared 
between  the  instrumentation  for  sensing  and  process  control,  and  the  knowledge  base  in 
the  computer.  The  direct  linkage  between  instrumentation  and  the  computer  would  per¬ 
mit  forward/backward  chaining,  thereby  providing  the  potential  for  recognition  of  prob¬ 
lems  as  they  occur.  The  intelligent  computer  would  suggest  what  needs  to  be  done  to 
correct  the  problem  and  the  operator  would  implement  this  suggestion.  In  this  phase,  the 
operator  action  would  yield  new  input  data  to  the  systenrr,  which  would  then  generate  a 
new  frame.  In  this  real-time  environment,  the  system  will  "learn"  as  a  function  of  oper¬ 
ator  action  and  the  resulting  cause-and-effect  relationships. 

4.  The  final  phase  would  generate  real-time  control,  which  would  free  the  operator 
from  routine  WWTP  O&M  and  rely  primarily  on  the  AI  system.  In  this  scenario,  the 
computer  would  operate  and  maintain  the  plant  by  adjusting  flow  and  recycle  rates;  turn¬ 
ing  on  and  off  valves,  pumps,  and  blowers;  adjusting  chemical  dosage;  lubricating  and 
replacing  parts;  and  whatever  else  is  needed  for  O&M.  Operator  intervention  would  be 
required  only  when  a  null  set  occurs  in  the  AI  system,  in  which  case  the  system  notifies 
the  operator  that  an  experience  has  occurred  for  which  information  is  not  available. 
Development  of  this  type  of  system  would  require  all  information  from  the  preceding 
three  phases  plus  computer  implementation  of  the  action  suggested  in  the  first  stage  of 
AI  development.  Under  this  system,  a  computer-initiated  action  would  yield  a  new 
frame.  Thus,  the  chaining  would  appear  in  terms  of  "cause,  action,  effect,  cause,  action, 
effect,  etc."  If  backward  chaining  were  also  used,  the  reverse  of  the  above  scenario 
could  be  incorporated  in  parallel,  as  well— specifically,  "effect,  action,  and  cause;  effect, 
action,  and  cause;  etc."  The  framing  technique  proposed  would  produce  child  frames  as  a 
function  of  new  data  while  discarding  parent  frames.  As  time  passes,  efficiency  and 
sophistication  of  the  AI  operating  system  would  be  brought  into  sharper  focus  for  the 
specific  treatment  facility  to  which  the  AI  system  has  been  applied  in  a  generalized 
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form.  Therefore,  the  AI  system,  once  implemented  in  generic  form  would  evolve  to 
become  unique  to  the  specific  facility  as  a  function  of  the  learning  process  incorporated 
into  the  AI  procedure. 

Although  AI  technology  has  seen  impressive  progress  in  recent  years,  the  successes 
described  in  the  literature  tend  to  exaggerate.  At  present,  the  above  evolution  scenario 
sounds  exciting,  but  in  the  real  world,  the  technology  and  resource  limitations,  for 
example,  make  the  last  phase  infeasible  from  an  economic  perspective.  However,  AI 
applications  can  be  expected  to  continue  growing  rapidly  in  coming  years. 

In  this  study,  as  the  first  step  toward  AI  application  to  Army  WWTPs,  a  proof  of 
concept  approach  is  proposed  to  explore  the  possibility  of,  and  identify  problems  associ¬ 
ated  with,  this  application.  The  expert  system  in  this  study  was  constructed  and  tested 
by  a  Stanford  University  research  team.  The  following  portion  of  this  chapter  is  adopted 
from  the  Stanford  team  report.9 


Knowledge  Acquisition 

An  early  stage  in  creating  an  expert  system  involves  formalizing  the  problem-solv¬ 
ing  approach  of  one  or  more  individuals.  This  process  often  is  called  "knowledge  acquisi¬ 
tion."  According  to  Buchanan  and  Shortliffe, 1 0  knowledge  acquisition  is  "the  transfer 
and  transformation  of  problem-solving  expertise  from  some  knowledge  source  to  a  pro¬ 
gram."  A  clear  understanding  of  the  knowledge  acquisition  process  will  help  the  expert 
systems  developer  focus  on  the  integral  components  of  the  planned  system.  To  define 
the  knowledge  acquisition  process  for  this  study,  each  of  the  following  phrases  is 
defined:  "knowledge  source,"  "problem-solving  expertise,"  "transfer,"  and  "transforma¬ 
tion."  Some  concepts  not  included  explicitly  in  this  definition  (but  discussed  below)  con¬ 
cern  the  roles  of  the  system  builder,  otherwise  known  as  the  knowledge  engineer,  and  the 
system  user  in  knowledge  acquisition. 

Problem-Solving  Expertise 

The  problem-solving  ability  within  a  specific  domain  is  what  separates  experts  from 
novices.  This  ability,  usually  gained  after  prolonged  experience  with  a  specific  class  of 
problems,  allows  the  expert  to  solve  problems  quickly  and  efficiently.  Experts  rely  on 
facts,  combined  with  procedural  and  heuristic  problem-solving  methods.  Facts  include 
statements  such  as,  "the  dissolved  oxygen  is  4.5  mg/L,"  and  "the  primary  clarifier  was 
built  in  1978."  Procedures  include  methods  for  activities  such  as  collecting  and  analyzing 
laboratory  samples,  cleaning  and  lubricating  a  pump,  and  calculating  the  sludge  removal 
rate.  Some  procedures  take  the  form  of  algorithms— computational  methods  guaranteed 
to  provide  a  correct  (or  "optimal")  solution  in  a  finite  period  of  time,  or  to  conclude  that 
there  is  no  possible  solution.  Other  problem-solving  methods  are  heuristic,  often  consist¬ 
ing  of  rules  of  thumb  that  include  symbolic  information  such  as:  "if  the  primary  clarifier 
effluent  solids  are  too  high  and  gas  bubbles  are  rising  to  the  surface,  then  the  sludge  has 


9L.  Ortolano  and  C.  Perman,  Development  of  a  Conceptual  Plan  for  the  Exploitation  of 
Artificial  Intelligence  in  the  Diagnosis  of  Operational  Problems  at  Army  Wastewater 
Treatment  Facilities,  Draft  Report,  DACA  88-86-0247  and  DACA  88-86-0008  (Depart¬ 
ment  of  Civil  Engineering,  Stanford  University,  May  1987). 

1  °B.  Buchanan  and  E.  Shortliffe  (Eds.),  Rule-Based  Expert  Systems:  The  MYCIN  Experi¬ 
ments  of  the  Stanford  Heuristic  Programming  Project  (Addison-Wesley,  1984). 
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become  anaerobic  and  is  overflowing  the  weirs."  An  interesting  characteristic  of  heuris¬ 
tics  is  that,  although  they  often  solve  problems,  they  are  not  guaranteed  to  provide  opti 
mal  solutions.  Much  of  the  knowledge  acquisition  process  is  concerned  with  defining  the 
heuristic  problem-solving  techniques  used  by  experts. 

Knowledge  Sources 

In  building  an  expert  system,  knowledge  is  gathered  from  both  public  and  private 
sources.  Public  sources  include  documents  prepared  by  the  Environmental  Protection 
Agency  (EPA)  and  the  Water  Pollution  Control  Federation  (WPCF).  Generally,  the  public 
knowledge  source  consists  of  all  material  available  as  public  domain,  including  material 
in  textbooks,  regulations,  and  videotapes.  Public  knowledge  is  available  to  more  than  one 
individual  and  is  subject  to  peer  review. 

Expert  systems  rely  heavily  on  private  knowledge— especially  the  individual  experts 
in  a  field.  Often,  private  knowledge  has  not  been  formally  documented  and,  in  some 
cases,  individuals  may  never  have  discussed  their  problem-solving  approaches  with  any¬ 
one  or  had  them  reviewed  by  other  individuals.  Although  public  knowledge  is  used  to  the 
extent  possible,  knowledge  acquisition  focuses  mainly  on  the  knowledge  held  privately  by 
individuals. 

Knowledge  Transfer  and  Transformation 

Transferring  knowledge  means  extracting  and  recording  it  from  both  public  and  pri¬ 
vate  sources.  Extracting  knowledge  from  public  sources  is  a  well  known  exercise.  The 
challenge  of  knowledge  transfer  lies  with  extracting  personal  knowledge  from  individ¬ 
uals.  The  knowledge  acquisition  process  must  be  structured  such  that  the  individual's 
knowledge  is  captured  and  articulated  in  a  way  that  allows  it  to  be  recorded.  Three  con¬ 
ditions  have  caused  the  knowledge  acquisition  process  to  be  called  "ad  hoc"  and  charac¬ 
terized  as  being  fraught  with  difficulties  and  frustrations:  the  nature  of  private  know¬ 
ledge,  including  its  heuristic  aspects;  the  dependence  on  an  expert's  ability  to  communi¬ 
cate;  and  the  importance  of  the  knowledge  engineer's  ability  to  listen. 

In  the  context  of  expert  systems,  the  transfer  of  private  knowledge  involves  two- 
way  communication  between  the  expert  and  another  individual,  called  the  "knowledge 
engineer."  Sometimes  experts  can  record  their  problem-solving  expertise  independ¬ 
ently.  An  advantage  of  using  a  knowledge  engineer,  however,  is  that  he  or  she  can  con¬ 
tribute  an  objective  view  of  which  knowledge  is  pertinent  to  the  planned  expert  system 
and  often  can  direct  experts  in  unraveling  methods  that  they  may  never  have  formally 
identified.  The  assistance  provided  by  the  knowledge  engineer  can  save  the  expert  time 
during  system  development. 

Methods  used  or  formalized  in  communicating  knowledge  from  the  expert  include: 
discussions  and  interviews  organized  by  a  knowledge  engineer,  surveys,  interactive  com¬ 
puter  programs,  the  expert's  critique  of  implemented  prototype  expert  systems,  and 
reactions  of  one  expert  to  points  raised  by  another.1  1 

The  transformation  of  knowledge,  also  the  knowledge  engineer's  responsibility,  con¬ 
sists  of  changing  the  recorded  knowledge  into  formal  expressions  suitable  for  an  expert 
system's  programming  environment.  AI  specialists  have  developed  many  schemes  for 

1  ‘P.  Sell,  Expert  Systems:  A  Practical  Introduction  (Halsted  Press,  John  Wiley  and  Sons, 
1985);  F.  Hayes-Roth,  D.  Waterman,  and  D.  Lenat. 


representing  expertise  in  a  programmable  format,  including  predicate  calculus,  n-tuples, 
semantic  nets,  frames,  inference  methods,  and  production  rules.12  m  cases  for  which 
specific  software  and  hardware  have  been  chosen,  the  knowledge  engineer  must  adapt  the 
recorded  problem-solving  expertise  to  the  syntax  and  representation  schemes  available. 
One  of  the  indirect  accomplishments  of  the  transformation  process  is  clarification  of  the 
expert's  heuristic  reasoning  process.  Since  an  explanation  of  the  reasoning  process  is 
included  as  part  of  an  expert  system,  clarity  of  expression  is  a  requirement  in  formal¬ 
izing  heuristic  knowledge. 

One  method  of  creating  production  rules  based  on  case  study  examples,  called 
"induction,"  is  implemented  with  the  help  of  specialized  software. 13  Induction  is  based 
on  a  set  of  case  studies,  provided  by  the  expert,  which  consists  of  different  types  of 
problem-solving  decisions  (e.g.,  a  "training  set")  and  a  set  of  relevant  factors  called 
"attributes"  that  influence  decision.  The  induction  algorithm  uses  the  training  set  to 
induce  general  principles,  thereby  formulating  a  generalized  decision  process  and  enab¬ 
ling  the  prediction  of  decisions  for  problem  examples  not  included  in  the  training  set. 
The  induction  method  is  most  useful  in  the  later  stages  of  the  knowledge  acquisition 
process  when  the  expert,  sometimes  with  the  help  of  a  knowledge  engineer,  has  compiled 
a  large  number  of  case  studies. 

The  Knowledge  Engineer  end  the  System  User 

The  knowledge  engineer  is  responsible  for  facilitating  the  knowledge  transfer,  tran¬ 
scribing  and  formalizing  the  knowledge  and,  in  some  cases,  implementing  the  expert  sys¬ 
tem.  Sometimes  several  knowledge  engineers  work  as  a  team;  in  other  situations,  a 
single  person  carries  out  all  knowledge  acquisition  tasks.  When  the  knowledge  acquisition 
process  is  based  on  interviews  and  discussions,  the  knowledge  engineer  takes  an  active 
role  in  the  knowledge  transfer.  In  this  context,  the  knowledge  engineer,  either  cons¬ 
ciously  or  unconsciously,  can  filter  the  knowledge  by  selecting  or  altering  information  as 
it  is  recorded  and  formalized.  It  is  crucial  that  the  experts  have  an  opportunity  to 
review  and  refine  the  recorded  material  and  its  implemented  version.  In  some  circum¬ 
stances,  the  knowledge  engineer  can  also  function  as  a  knowledge  source.  For  example, 
the  knowledge  engineer  might  have  some  expertise  in  the  problem-solving  area. 
Although  the  knowledge  engineer's  abilities  may  be  less  refined  than  the  expert's,  they 
may  be  sufficient  to  contribute  knowledge  to  the  expert  system. 

The  users  are  the  individuals  who  ultimately  employ  the  production  version  of  the 
expert  system.  If  they  dislike  the  system,  feel  uncomfortable  with  it,  or  fail  to  find  it 
useful  or  worth  the  time  it  takes  to  learn,  they  will  not  use  it.  Consequently,  identifying 
the  user's  needs  is  essential  to  the  design  and  implementation  of  the  expert  system.  By 
consulting  the  users  at  the  start  of  knowledge  acquisition,  they  become  a  knowledge 
source— not  so  much  for  problem-solving  expertise,  but  for  giving  feedback  on  the  appro¬ 
priateness  of  the  input  and  output  and  on  the  effectiveness  of  the  explanation  facility. 
Knowledge  acquired  from  consulting  with  the  user  applies  specifically  to  the  expert  sys¬ 
tem's  ability  to  communicate  with  the  user  (i.e.,  interface  design)  and  the  content  of  the 
explanation  facility.  If  the  explanation  facility  does  not  fulfill  the  user's  needs,  then  the 
expert  system  is  not  attaining  one  of  the  defining  characteristics  of  such  a  system:  clar¬ 
ifying  the  program  function  to  the  user. 


12N.  Nilsson,  Principles  of  Artificial  Intelligence  (Tioga  Publishing  Co.,  Palo  Alto,  CA, 
1980);  E.  Rich,  Artificial  Intelligence  (McGraw-Hill,  1983). 

13A.  Hart,  "The  Role  of  Induction  in  Knowledge  Elicitation,"  Expert  Systems ,  Vol  2,  No. 
1  (1985),  pp  24-28. 
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Knowledge  Acquisition  Methods  for  Developing  a  Prototype 


The  Stanford  University  research  team  conducted  a  knowledge  acquisition  exercise 
as  a  part  of  this  study.  The  exercise  serves  to  demonstrate  the  feasibility  of  using  A!/ 
expert  systems  in  developing  a  prototype  for  WWTP  O&M  at  Army  installations.  The 
researchers  served  as  the  knowledge  engineers,  with  five  experts  and  one  user  (a  novice 
operator)  selected  to  complete  the  team.  The  knowledge  was  used  to  create  a  proof-of- 
concept  system  called  "Sludgecadet,"  which  was  developed  and  tested  for  an  isolated  part 
of  the  O&M  process.  The  exercise  and  the  Sludgecadet  system  are  summarized  below. 

Selecting  the  Expert 

What  are  the  appropriate  criteria  for  selecting  an  expert?  As  a  praefi'ca!  matter, 
the  expert  is  someone  who  is  regarded  by  those  interested  in  solvin;  the  problem  as  hav¬ 
ing  an  outstanding  record  of  accomplishment. 

For  this  study,  an  "expert"  was  defined  as  a  person  who  meets  the  following  cri¬ 
teria: 


•  Diagnosis  and  repair  expertise 

•  Interest  in  participating 

•  Familiarity  with  Army  facilities 

•  Ability  to  communicate  effectively 

•  Computer  literacy 

•  Compatibility  with  the  knowledge  engineer 

•  Time  availability. 

Based  on  these  criteria,  five  experts  were  selected— three  from  ES2  Engineers, 
Berkley,  CA,  and  two  operations  foremen  from  the  Fort  Lewis,  WA,  WWTP.  The  ES2 
Engineers  experts  provided  general  expertise  in  diagnosing  problems  and  recommending 
actions  while  the  Fort  Lewis  foremen  supplied  site-specific  knowledge  for  building  the 
expert  system. 

Transferring  Knowledge  From  Experts 

The  team  planned  to  transfer  knowledge  from  the  experts  to  the  computer  program 
in  cycles,  with  each  cycle  consisting  of  the  following  steps:  interview,  transformation, 
implementation,  demonstration,  review,  and  refinement.  Interviews  were  used  to  gather 
new  knowledge  which  was  then  transformed  into  programmable  form.  Implementation  of 
the  knowledge  as  a  component  of  the  prototype  expert  system  was  then  demonstrated  to 
the  experts  and  their  review  comments  were  used  to  refine  it.  The  experts  were  involved 
at  the  interview,  demonstration,  review,  and  refinement  stages,  whereas  the  knowledge 
engineers  participated  in  all  stages.  Each  cycle  began  by  collecting  the  more  general 
expertise  from  the  ES2  experts  and  ended  by  having  the  Fort  Lewis  foremen  add  site- 
specific  expertise. 

During  each  interview,  the  knowledge  engineers  and  an  expert  developed  a  test 
case.  The  various  elements  of  the  expert's  problem-solving  techniques  were  revealed  by 
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examining  how  the  expert  discovered  a  problem  symptom,  how  the  cause  of  the  various 
symptoms  were  diagnosed,  and  how  a  particular  remedial  action  was  recommended.  The 
rules  articulated  in  the  context  of  the  test  cases  came  from  the  expert's  own  exper¬ 
iences.  Other  rules  were  deduced  from  an  expert's  reactions  to  case  histories  developed 
by  other  experts  and  reported  in  the  literature.  After  these  interviews,  the  knowledge 
engineers  formalized  and  added  each  test  case  to  the  developing  expert  system. 

The  next  step  in  transferring  knowledge  from  the  expert  consisted  of  soliciting  the 
expert's  reactions  to  the  formalized  and  implemented  test  cases  with  a  demonstration  of 
the  expert  system.  The  expert's  feedback  was  valuable  in  several  ways,  the  most  import¬ 
ant  of  which  was  to  validate  the  correctness  of  the  work  done  by  the  knowledge  engi¬ 
neers  in  transferring  knowledge  from  the  expert  to  the  program.  During  the  demonstra¬ 
tion,  the  knowledge  engineers  and  the  expert  verified  that  the  program  was  emulating 
the  expert's  problem-solving  techniques.  The  demonstration  also  provided  a  forum  for 
reviewing  the  clarity  and  ease  of  use  of  the  demonstration  system's  interface. 

First  Cycle  of  Knowledge  Acquisition 

The  knowledge  transfer  process  began  with  a  seminar  presented  to  the  ES2  Engin¬ 
eers.  It  included  an  introduction  to  expert  systems  and  the  knowledge  acquisition  process 
along  with  a  demonstration  of  an  experimental  rule-based  system  that  was  written  in 
INSIGHT  (PC-based  software)  for  diagnosing  problems  in  a  trickling  filter.  The  ES2 
Engineers  recommended  starting  with  the  primary  sedimentation  (clarifying)  tank 
because  it  would  have  an  appropriate  level  of  complexity. 

The  first  test  case  was  developed  during  an  informal  interview  while  a  knowledge 
engineer  tape-recorded  the  conversation.  The  expert  took  an  active  role  in  the  knowl¬ 
edge  acquisition  exercise  by  acting  as  if  he  were  teaching  the  knowledge  engineers  how 
to  solve  tne  test  case. 

Using  the  information  from  this  interview,  the  knowledge  engineers  implemented 
the  first  version  of  Sludgecadet,  the  proof-of-concept  system  discussed  in  the  next  sec¬ 
tion.  To  validate  the  implemented  knowledge,  the  Sludgecadet  system  was  demonstrated 
to  experts  for  their  review.  All  participants  watched  the  expert  system  work  and  were 
given  the  opportunity  to  use  it  themselves.  Their  comments  were  detailed  and  empha¬ 
sized  the  choice  of  specific  words  and  phrases  used  in  the  system.  Since  they  found  the 
underlying  reasoning  and  facts  to  be  represented  correctly,  their  comments  emphasized 
the  need  to  make  Sludgecadet  understandable  and  accessible  to  the  novice  WWTP  opera¬ 
tor. 


On  an  earlier  site  visit,  the  knowledge  engineers  had  obtained  a  copy  of  the  Fort 
Lewis  O&M  manual.  Using  this  information,  the  knowledge  engineers  prepared  a  version 
of  Sludgecadet  that  transferred  the  general  solution  of  the  total  suspended  solids  problem 
to  the  Fort  Lewis  plant.  This  version  of  Sludgecadet  contained  all  facts  and  knowledge 
from  the  Fort  Lewis  plant  that  applied  to  the  test  case.  The  experts  reviewed  this  ver¬ 
sion,  focusing  on  its  details  and  determining  its  applicability  to  the  Fort  Lewis  WWTP. 


Technical  Feasibility  of  the  Sludgecadet  System 

The  purpose  of  the  Sludgecadet  proof-of-concept  system  was  to  apply  the  process 
of  building  an  expert  system  to  a  representative  diagnostic  problem.  With  help  from  the 
participating  experts,  the  team  focused  on  diagnosing  and  recommending  remedial  action 
for  a  specific  operating  problem:  abnormally  high  total  suspended  solids  (TSS)  in  the  pri¬ 
mary  clarifier  effluent.  The  first  version  of  Sludgecadet  consisted  of  facts,  calculations. 
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ana  diagnostic  and  remedial  expertise  that  is  transferable  to  individual  sites  in  the 
category  of  WWTPs  with  trickling  filters  for  secondary  treatment  and  anaerobic  digest¬ 
ers  for  sludge  treatment.  In  addition,  this  test  version  had  complete  user  interface  and 
explanation  facilities  that  had  been  reviewed  by  experts  and  potential  users  at  ES2 
Engineering  and  Fort  Lewis. 

Before  implementing  the  Sludgecadet  system,  the  following  tasks  were  necessary: 

1.  Compile  a  description  of  the  domain  knowledge 

2.  Formalize  the  information  resulting  from  the  knowledge  acquisition  exercise 

3.  Review  applicable  A!  programming  techniques 

4.  Choose  appropriate  software. 

To  support  the  technical  feasibility  of  the  Sludgecadet  proof-of-concept  system,  the 
results  of  each  task  are  described  below. 

Description  of  the  Domain  Knowledge 

During  the  knowledge  acquisition  process,  knowledge  was  compiled  primarily  from 
experts,  but  also  from  operating  manuals,  engineering  texts,  and  plant  engineering  des¬ 
criptions.  Since  the  focus  was  on  developing  an  expert  system  for  one  specific  type  of 
operating  problem,  the  team  concentrated  on  gathering  only  those  facts  and  problem¬ 
solving  techniques  applicable  to  that  problem.  From  the  various  sources,  it  was  estab¬ 
lished  that  the  acquired  knowledge  could  be  separated  into  three  categories:  facts  about 
the  treatment  plant  and  operating  data;  reasoning  for  making  diagnoses  and  recommend¬ 
ing  solutions;  and  calculations  for  the  various  empirical  and  dimensional  relationships  in  a 
WWTP. 

In  addition  to  categorizing  the  knowledge,  there  are  some  interesting  characteris¬ 
tics  in  the  domain  of  diagnosing  and  recommending  remedial  action  in  WWTPs.  These 
include  the  types  of  decisions  embedded  in  diagnosing  and  recommending  remedial  act¬ 
ions,  the  data  requirements  for  these  decisions,  and  the  operator's  level  of  expertise. 

Cortinovis  has  presented  a  conceptual  framework  to  describe  operating  decisions  in 
four  categories: 1 14 

o  Planning  Decisions:  preparing  for  new  or  expanded  facilities,  formulating  staf¬ 
fing  plans,  and  preparing  budgets 

0  Administrative  Decisions:  dealing  with  personnel,  boards,  regulatory  agencies, 
and  the  public 

o  Process  Decisions:  setting  targets  for  process  parameters 

o  Operating  Decisions:  making  necessary  changes  on  each  shift  to  keep  the  plant 
on  target  for  process  parameters. 


'“D.  Cortinovis,  Controlling  Wastewater  Treatment  Processes  (Ridgeline  Press,  Lafay¬ 
ette,  CA,  1984). 
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Of  these  four  categories,  diagnosing  and  recommending  remedial  actions  are 
grouped  under  "process  decisions"  and  "operating  decisions."  Each  type  of  decision  can 
be  based  on  heuristics  or  algorithms.  Heuristics  include  qualitative  or  symbolic  problem¬ 
solving  rules  developed  from  operating  experience.  An  example  of  a  heuristic  rule  for 
diagnosing  problems  with  trickling  filter  processes  is:  "If  the  trickling  filter  has  an  ob¬ 
noxious  odor  problem,  the  wastewater,  sludge,  or  biological  growths  have  become  anaer¬ 
obic."  1 5 


Algorithms  include  empirical  or  theoretical  models.  A  solids  mass  balance  calcula¬ 
tion  is  an  example  of  an  algorithm  that  would  be  used  to  test  process  performance. 
Computers  have  been  useful  in  helping  the  operator  make  such  calculations. 

During  treatment  plant  operations,  the  operator  must  respond  to  changes  in  plant 
status  by  "taking  action."  Sometimes  taking  action  means  establishing  routine  activities 
such  as  sampling,  buying  supplies,  and  scheduling  maintenance.  At  other  times,  the  oper¬ 
ator  must  take  action  in  response  to  adverse  process  conditions.  Some  typical  operator 
actions  are: 1 6 

•  Set  operations  goals  and  targets  for  process  parameters 

•  Take  physical  action,  e.g.,  change  flow,  add  chemicals,  repair  broken  equipment 

•  Maintain  automatic  control  equipment,  e.g.,  if  automatic  control  equipment  is 
installed,  the  operator  is  responsible  for  setting  the  automatic  control  parame¬ 
ters  as  well  as  maintaining  the  equipment 

•  Determine  if  additional  expertise  is  required  to  solve  an  operational  problem. 

To  run  a  WWTP,  the  operating  staff  must  keep  track  of  the  present  state  of  the  on¬ 
going  processes.  This  status  is  evaluated  by  indicators  that  show  influent  flow  rate,  tem¬ 
perature,  pH,  biological  oxygen  demand  (BOD),  settleable  solids,  SS,  color,  odor,  and  pro¬ 
cess  turbulence  patterns.  Some  of  the  indicators  are  measured  empirically;  others  are 
based  on  the  operator's  subjective  observations.  The  empirical  data  are  associated  with 
standard  units  of  measurement;  the  subjective  data  have  no  standard  of  measurement. 
Methods  of  collecting  information  about  these  indicators  include  personal  observations, 
manual  sample  collection  and  laboratory  analysis,  and  automatic  data  collection. 

One  of  the  operator's  essential  duties  is  to  walk  through  the  plant  and  observe  its 
present  state.  Familiarity  with  the  plant,  coupled  with  personal  observations,  are  essen¬ 
tial  to  being  an  effective  operator.  Also,  plant  processes  are  dynamic;  the  operator  must 
understand  the  impact  of  changes  on  the  plant.  Since  each  plant  is  unique,  operator 
training  is  most  effective  with  hands-on,  site-specific  conditions. 

Laboratory  results  and  measured  parameters  are  necessary  to  operation  and  serve 
to  enhance,  rather  than  replace,  direct  operator  observations.  Laboratory  analysis  is  an 
empirical  method  for  collecting  data  about  the  status  of  a  plant.  Aside  from  being 
required  by  Federal,  State,  and  local  regulatory  agencies,  such  analysis  is  also  vital  to 
the  operator  for  monitoring  and  interpreting  plant  conditions.  Without  laboratory 
results,  the  operator  can  only  guess  at  what  is  happening  in  the  plant. !  7 


ISD.  Cortinovis,  et  al.,  The  Activated  Sludge  Process:  Fundamentals  of  Operation  (Ann 
Arbor  Science,  1983). 

I6D.  Cortinovis;  D.  Cortinovis,  et  al. 

1 7D.  Cortinovis. 
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Formal  Representation  in  Sludgecadet 

The  first  step  in  testing  the  system's  feasibility  is  to  rewrite  the  acquired  knowl¬ 
edge  into  a  formal  documented  form  that  is  independent  of  a  specific  type  of  expert  sys¬ 
tem  or  programming  environment.  There  are  several  reasons  for  this  step.  First,  it 
forces  knowledge  engineers  to  restate  the  acquired  knowledge,  thus  checking  their  under¬ 
standing  of  the  domain.  It  also  provides  a  medium  for  validation  and  review  by  the  con¬ 
tributing  experts.  Finally,  since  the  knowledge  is  already  recorded  in  a  formal,  validated 
medium  independent  of  implementation  language,  it  allows  efficiency  in  rewriting  the 
same  system  in  a  different  language. 

After  formalizing  the  knowledge,  the  team  designed  five  basic  features  and  capa¬ 
bilities  of  the  Sludgecadet  system  which  include: 

1.  Storage  of  and  access  to  facts  about  the  plant.  Two  important  constraints  guide 
the  formalization  of  knowledge:  the  facts  describing  the  generic  and  site-specific  plant 
information  need  to  be  stored  separately,  and  there  needs  to  be  a  provision  for  high- 
capacity  data  storage  with  easy  updating  and  access,  such  as  a  database.  An  interesting 
feature  of  wastewater  treatment  facts  is  that  they  concern  complex  objects  with  physi¬ 
cal  meanings  and  behaviors.  For  example,  pumps  are  physical  objects  in  wastewater 
treatment  plants.  All  pumps  share  certain  attributes  (e.g.,  a  class,  a  model  number,  a 
pressure  rating,  etc.);  specific  pumps  have  specific  values  for  each  of  these  attributes. 

2.  Reasoning  for  making  diagnoses  and  recommending  remedial  action.  The  rea¬ 
soning  process  that  includes  diagnosis  and  recommendation  of  remedial  action  has  been 
formalized  frequently  in  the  expert  system  programming  environment.  These  systems 
have  represented  the  diagnostic  process  as  one  that  attempts  to  prove  a  hypothesis  about 
the  problem  (i.e.,  the  diagnosis)  by  searching  a  database  for  proven  facts  or  prompting 
the  user  for  confirmation  on  certain  questions  (i.e.,  new  symptoms).  This  reasoning  exer¬ 
cise  is  usually  called  a  "backward  chaining"  process  because  it  starts  with  a  posed  hypo¬ 
thesis,  tests  the  hypothesis  with  various  supporting  facts  (i.e.,  premises)  and,  if  the  pre¬ 
mises  are  true,  indicates  that  the  hypothesis  has  become  a  proven  solution.  The  diagnos¬ 
tic  process  is  represented  conveniently  by  statements  called  "production  rules"  in  an 
"if. ..then. ..else"  format. 

3.  Engineering  calculations.  The  ability  to  do  calculations  is  an  inherent  part  of 
any  computer  program  in  the  engineering  domain,  which  encompasses  wastewater  treat¬ 
ment.  The  need  for  computations  arises  in  many  situations:  transforming  raw  data  from 
samples  to  reportable  results,  checking  and  setting  the  operational  parameters,  creating 
required  plant  reports,  verifying  data,  and  diagnosing  problems.  Not  only  do  computa¬ 
tions  need  to  be  performed  from  within  the  reasoning  process,  but  the  Sludgecadet  sys¬ 
tem  also  must  provide  answers  to  computations  at  the  operator's  request. 

4.  Program  control.  This  feature  enables  the  user  to  control  execution  of  the 
expert  system;  these  tasks  include  inputting  data,  outputting  resuits,  requesting  engi¬ 
neering  computations,  accessing  the  database,  initiating  operating  problem  diagnosis  and 
recommending  remedial  action,  and  requesting  explanations. 

5.  User  interface  and  explanation.  The  user  interface  provides  tools  that  enable 
the  user  to  interact  with  the  expert  system  and  exercise  control  over  the  program. 
Unfortunately,  this  is  the  single  part  of  the  program  design  that  depends  on  the  software 
and  hardware  chosen  for  system  implementation.  Classically,  this  interaction  has  been 
based  on  text  input  and  output.  With  a  text-based  interface,  the  terminal  can  be  either  a 
teletype  (typewriter)  or  a  screen  on  which  the  lines  are  written  in  consecutive  order  from 


top  to  bottom.  With  both  graphics  monitors  and  software,  personal  computers  and  work¬ 
stations  can  provide  an  interface  based  on  menus,  pictures  and,  in  some  eases,  a  mouse- 
guided  cursor.  Most  importantly,  graphics  provide  the  entire  screen  to  the  user  for  both 
input  and  output.  A  typical  graphics  interface  consists  of  pictures  (i.e.,  bitmaps)  and 
menus  that  are  cursor-sensitive.  By  selecting  a  picture  or  menu  item  with  the  cursor, 
the  user  activates  a  part  of  the  software.  Cursor-sensitive  graphics  can  be  used  as  an 
interface  to  program  control  and  for  inputting  and  displaying  data. 

Another  aspect  of  the  expert  system's  interface  is  a  feature  that  explains  the  sys¬ 
tem  reasoning,  conclusions,  and  requests  for  information.  The  explanation  facilities  can 
reply  to  questions  that  are  posed  such  as,  why  the  user  is  asking  for  this  piece  of  data  or 
how  the  user  forms  that  diagnosis.  The  specific  design  of  the  explanation  facilities 
depends  as  much  on  the  capabilities  of  the  expert  system's  interface  as  it  does  on  the 
users'  needs  and  level  of  expertise.  For  this  reason,  it  is  to  the  advantage  of  the  system 
designer  to  be  able  to  work  in  a  programming  environment  that  provides  as  many  built-in 
features  as  possible  for  responding  to  the  system's  potential  users. 

AI  Programming  Techniques 

A1  offers  many  alternative  methods  for  implementing  the  representation  required 
by  the  Sludgecadet  system.  Of  these,  two  particularly  promising  Al  programming 
techniques  for  the  Army  WWTP  O&M  are  the  object-oriented  and  failure-driven  learning 
methods.  Although  the  former  was  used  in  this  exercise,  the  latter  has  some  advan¬ 
tages.  For  example,  a  failure-driven  system  would  have  lower  peripheral  storage  and 
software  development  costs.  Specifically,  the  parent  frames  would  contain  most  of  the 
decision  functions.  However,  disadvantages  are  the  time  required  for  software  evolution 
through  the  plant  failure  detection/eorrection  and  the  level  of  operator  skill  required 
during  the  training  phase. 

Nilsson  has  stated  that  the  appropriateness  of  the  representation  depends  on  the 
application;  further,  efficient  storage,  retrieval,  and  modification  are  key  concerns  in 
selecting  an  implementation  design.'-8  Considering  the  enormous  amount  of  information 
on  O&M  of  WWTPs,  the  developmental  team  chose  an  object-oriented  programming  style 
as  the  guiding  framework  for  designing  the  implementation. 

Object-oriented  programming  focuses  on  the  use  of  formal  data  structures  as  the 
heart  of  the  implementation  code.  In  its  logical  extent,  object-oriented  programming 
refers  to  all  code  units  such  as  variables  or  functions  (i.e.,  subroutines)  as  objects. 
"Objects"  usually  refer  to  items  in  the  real  world  that  have  physical  meaning.  A  useful 
application  of  object-oriented  programs  is  as  an  interface  to  information  in  a  database. 
For  example,  rather  than  pull  information  from  a  database  into  a  program's  variables  and 
then  process  it,  object-oriented  programming  provides  a  paradigm  for  referring  to  and 
processing  the  information  directly  in  the  database.  The  most  advantageous  way  to  use 
this  style  of  programming  is  with  system  development  tools  that  provide  a  procedural  and 
production  rule  system  using  an  object  oriented  style  and  capabilities  for  database 
information  processing. 

One  AI  programming  technique  for  organizing  information  about  a  specific  object  is 
a  type  of  data  structure  called  "frames."  Frames  are  data  structures  identified  by  a 
unique  name  and  consist  of  a  set  of  attributes  and  attribute  values  describing  the 
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object.19  Frames  often  are  organized  into  a  hierarchical  database,  with  some  frames 
representing  general  level  "class"  objects  and  others  detailed  level  "instance"  objects. 
Class-level  frames  can  be  considered  as  parent  objects  that  pass  on  their  attributes  to 
instance  or  child  frames.  When  a  new  child  frame  is  created,  it  will  automatically 
inherit  the  attributes  of  the  parent  unit,  thus  establishing  an  efficient  method  for  gener¬ 
ating  and  organizing  information  in  the  database. 

Expert  systems  comprise  a  branch  of  AI  programming  designed  to  accommodate  the 
following  features:  expert-level  solutions  to  complex  problems,  solutions  that  are  under¬ 
standable  to  the  user,  and  a  flexible  design  that  accepts  new  knowledge.20  As  was  shown 
in  Figure  l  and  discussed  earlier,  the  two  main  parts  of  an  expert  system  are  the 
knowledge  base  and  the  inference  engine.  Depending  on  the  expert  system  programming 
tool  being  used,  inference  engines  include  different  types  of  controlling  strategies  for 
scanning  the  facts  and  ordering  the  rule-testing  sequence.  Two  examples  of  inference 
control  strategies  are  forward-chaining  and  backward-chaining.  A  forward-chaining 
strategy  is  considered  to  be  data-driven  because  it  triggers  with  the  assertion  of  facts 
that  form  rule  premises.  Backward-chaining  is  called  a  "goal-directed"  strategy  because 
it  tests  the  validity  of  a  specific  rule  conclusion  by  searching  the  knowledge  base  for 
valid  facts  in  associated  rule  premises.  Expert  systems  with  this  design  often  are  called 
"production  systems,"  and  the  encoded  rules  are  called  "production  rules." 

"Daemons"  are  rule-based  or  procedural  items  of  code  that  execute  when  a  certain 
attribute's  value  changes.  A  daemon  is  attached  to  an  attribute  and  constantly  monitors 
the  condition  of  the  attribute  value.  When  the  value  changes,  the  daemon  executes. 
Daemons  are  so  called  because  they  do  not  require  explicit  control  by  the  user,  but  are 
often  activated  as  "side  effects"  when  some  other  procedure  changes  an  attribute's  value. 

It  was  clear  that  the  object-oriented  style  database  would  be  advantageous  for 
Sludgecadet,  producing  a  system  with  a  procedural  language  for  program  control  and  cal¬ 
culations  as  well  as  a  database  for  storing  the  ^lant  and  operating  data.  Other  desirable 
features  included  object-oriented  production  rules  with  flexible  inference  mechanisms, 
including  forward  and  backward  chairing;  high-level  control  of  text;  and  graphics  inter¬ 
face  and  explanation  facilities. 

Choosing  Implementation  Software 

The  workstation  (e.g.,  LISP  machine  or  general-purpose  unit)  environment  was 
chosen  over  the  PC  because  the  specific  needs  of  the  application  should  dictate  software 
selection. 

The  Sludgecadet  system  was  tested  and  then  implemented  in  a  Knowledge  Engi¬ 
neering  Environment  (KEF.)  that  resides  in  a  LISP-based  workstation.  Of  its  many  fea¬ 
tures,  those  most  applicable  to  the  proof-of-eoncept  version  of  Sludgecadet  are:  frames 
that  form  a  database  of  objects  connected  by  attribute  inheritance  relationships;  proce¬ 
dural  programming  language  (LISP),  accessed  cither  by  message  passing  between  objects 
or  as  explicitly  invoked  functions;  built-in  explanation  facilities;  and  a  machine-inde¬ 
pendent,  high-level  graphics  package  for  building  a  customized  user  interface. 

At  the  center  of  KEE  are  frame-based  objects  called  "units."  Frames  are  collected 
into  a  knowledge  base  (KB).  They  can  exist  independently  in  a  KB  or  can  be  linked  by 
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relationships.  Specifically,  KEE  provides  "child  of"  or  "parent  of"  links.  With  these  links, 
the  child  frames  can  inherit  attributes  of  their  parent  frames.  Parent  frames  describe 
classes  of  objects. 

KEE  has  another  feature  called  "active  values,"  sometimes  known  as  daemons.  This 
feature  can  be  invaluable  for  maintaining  and  updating  dependent  values  in  the  plant  and 
operating  database.  In  KEE,  daemons  are  stored  as  method  attributes  on  a  special  kind 
of  unit  that  is  a  child  of  the  class  "active  values." 

KEE  also  provides  a  practical  delivery  or  run-time  environment  called  "PC-Host." 
The  premise  of  the  delivery  environment  is  that  the  system  developer  designs  and  imple¬ 
ments  the  expert  system  on  a  LISP  workstation,  then  shifts  (i.e.,  "ports")  the  expert  sys¬ 
tem  code  to  a  VAX  (e.g.,  that  operates  under  VMS).  By  residing  on  a  VAX,  the  expert 
system  can  be  accessed  by  users  with  IBM-compatible  PCs  through  a  telephone  or  net¬ 
work  communication  line.  The  IBM  PC  must  have  certain  features:  at  least  512K  mem¬ 
ory,  a  graphics  card  and  monitor,  and  some  form  of  communication  capability.  However, 
the  required  configurations  are  fairly  standard  and  most  PCs  already  have  graphics  and 
communications  features. 

Implementation  of  Sludgecadet 

The  representation  described  above  was  tested  by  implementing  the  Sludgecadet 
prototype  for  the  problem  of  abnormally  high  TSS  in  the  primary  clarifier  effluent.  The 
Sludgecadet  expert  system  can: 

•  Recognize  that  an  operating  problem  involves  the  primary  clarifier  and  offer  a 
possible  diagnosis 

•  Diagnose  a  problem  or,  if  unable  to  infer  a  diagnosis,  state  that  diagnosis  is  un¬ 
known 

•  Represent  the  physical  objects  of  a  wastewater  treatment  plant  (e.g.,  unit  pro¬ 
cesses,  subsystems,  specific  parts,  wastewater  and  sludge  streams) 

•  Provide  a  graphics-oriented  interface  that  emphasizes  use  of  menus  and  a 
mouse. 

This  exercise  was  implemented  with  the  same  AI  programming  techniques  that 
would  be  used  in  a  production  version  of  the  Sludgecadet  system.  The  current  version  of 
Sludgecadet  consists  of  two  KEE  KBs:  the  first  named  SLUDGECADET  for  knowledge 
that  is  transferable  between  locations  and  the  second  named  FORTLEWIS  for  the  chosen 
test  site.  These  KBs  contain  all  codes  that  implement  the  facts,  production  rules,  and 
most  of  the  interface  within  frames  (or  KEE  units).  The  only  code  not  stored  in  the  two 
KBs  is  the  LISP  code  required  for  procedural  control  of  the  program. 

The  SLUDGECADET  KB  can  be  displayed  graphically  (Figure  2)  as  a  "KB  graph" 
with  inheritance  of  attributes  shown  explicitly  by  connecting  lines  between  the  units.  In 
the  KB  graph,  each  unit  is  represented  by  name;  to  the  left  are  the  parent  units  and  to 
the  right  are  the  children  units.  In  other  words,  attributes  are  passed  from  left  to  right 
(from  parents  to  children);  the  more  general  units  (class-level)  are  distinguished  by  being 
on  the  left  end  of  a  connecting  line;  the  more  specific  units  (those  representing  instances 
where 
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Figure  2.  Graph  of  the  Sludgecadet  knowledge  base. 
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of  physical  objects)  are  on  the  right  end  of  a  dashed  line.  The  frame  representation  in 
the  SLUDGECADET  KB  includes: 


1.  Environment.  The  frame  ENVIRONMENT  serves  as  an  organizational  frame  for 
other  class  frames  that  describe  characteristics  of  the  geography,  service  community, 
time,  and  climate. 

2.  Operating  calculations.  This  is  the  parent  frame  for  all  calculations  required  in 
the  TSS  problem.  All  information  needed  for  a  specific  type  of  calculation  is  stored  in 
each  instance  frame's  attributes. 

3.  SC  (Sludgecadet)  rules.  In  KEE,  each  production  rule  is  stored  as  a  special  type 
of  frame  instance.  Each  rule  is  stored  in  the  instance  frames  at  the  right  of  the  SC 
RULES  hierarchy.  Sludgecadet  has  two  classes  of  rules:  one  for  a  preliminary  analysis 
of  a  new  problem  called  CLASSIFY  PROBLEMS  RULES  AND  DIAGNOSIS  RULES.  For 
this  problem,  a  specific  class  of  rules  called  PRIMARY  DIAGNOSIS  RULES  was  created. 

4.  Operating  information.  In  the  Sludgecadet  design,  each  operating  problem  is 
described  by  a  specific  frame  in  order  to  record  a  history  of  operating  problems.  That 
class  frame,  OPERATING  PROBLEMS,  is  the  parent  unit  for  each  problem  frame. 

5.  Plant  description.  The  object  WASTEWATER  TREATMENT  PLANT  collects  the 
class-level  objects:  FLUIDS,  PARTS,  PROCESS  UNITS,  and  SUBSYSTEMS.  FLUIDS  is 
the  parent  unit  for  the  classes  SLUDGE,  WASTEWATER,  and  CLEAN  WATER,  which  in 
turn  are  parents  of  the  various  types  of  fluids  found  in  WWTPs.  The  object  instance 
TEST  PRIMARY  CLARIFIER  SLUDGE  was  used  to  test  the  rule  and  was  replaced  by  Fort 
Lewis  object  instances.  The  PARTS  object  is  the  parent  frame  for  specific  categories  of 
plant  parts.  The  various  unit  process  frames  fall  under  the  PROCESS  UNITS  class.  The 
SUBSYSTEMS  unit  represents  plant  parts  usually  designated  as  a  group  (e.g.,  the  sludge 
collection  system). 

The  FORTLEWIS  KB  (Figure  3)  was  created  by  running  an  installation  procedure  on 
the  SLUDGECADET  KB  that  creates  all  requisite  frames  and  queries  the  user  for  all 
values  that  describe  a  specific  WWTP.  The  attributes  for  the  FORTLEWIS  KB  frames  do 
not  have  to  be  completely  recreated  because  they  are  all  inherited  from  the  associated 
parent  frame  in  the  SLUDGECADET  KB. 

The  attributes  (called  "own  slots"  in  KEE)  inherited  by  the  unit  PRIMARY  CLARI¬ 
FIER  1  (Figure  4)  include:  ACTUAL  SLUDGE  PUMPING  RATE,  DESIGN  SLUDGE 
PUMPING  RATE,  DOWNSTREAM,  EFFLUENT,  EFFLUENT  SS,  FRACTION  DRY  SOLIDS 
IN  SLUDGE,  and  GAS  BUBBLES.  Each  slot  has  several  subdivisions  called  "facets"  such 
as  Inheritance,  ValueClass,  Cardinality  Max,  Comment,  and  Values.  The  Inheritance 
facet  specifies  the  way  in  which  the  slot  inherits  the  value  facet  from  a  parent  unit;  in 
the  slot  ACTUAL  SLUDGE  PUMPING  RATE  (top  slot  of  Figure  4)  the  inheritance  of 
override  values  means  that  the  value,  in  this  case  15,  is  unique  to  the  unit  PRIMARY 
CLARIFIER  1  and  has  not  been  inherited  from  the  PRIMARY  CLARIFIERS  parent  unit. 
The  ValueClass  facet  declares  that  the  value  of  the  slot  must  belong  to  a  certain  cate¬ 
gory  which  in  this  slot  is  a  number.  A  Cardinality  Max  establishes  the  upper  limit  of  the 
number  of  distinct  values  on  the  Values  facet.  A  Cardinality  Max  of  "1"  means  that  the 
slot  can  have  only  one  value  at  a  time.  The  values  in  the  rest  of  the  slot  of  PRIMARY 
CLARIFIER  1  reflect  the  current  state  of  the  KB  after  diagnosing  the  TSS  problem. 
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Figure  4.  The  PRIMARY  CLARIFIER  1  frame  and  attributes. 
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One  of  the  rules  used  in  diagnosing  the  TDS  problem  is  called  the  "Primary  Clari¬ 
fier  Problem  Rule"  and  is  stored  in  a  frame  of  the  same  name  (Figure  5).  All  of  a  rule 
frame's  attributes  are  inherited  from  the  high-level  KEE  frame  called  RULES.  A  system 
developer  enters  a  rule  into  a  KB  by  storing  it  in  the  value  facet  of  the  EXTERNAL 
FORM  slot  of  a  rule  frame  (see  the  fourth  slot  in  Figure  5).  The  rule  text  is  in  a  LISP- 
like  form  with  each  premise  enclosed  by  parentheses.  Most  premises  have  the  format 
"the  slot  of  frame  is  value,"  thus  associating  each  rule  premise  to  frame-based  informa¬ 
tion  in  the  KB.  The  "?Problem"  and  "?Unit.process.location"  terms,  which  are  distin¬ 
guished  from  other  terms  by  a  question  mark,  are  KEE  rule  variables.  By  using  the  ?Pro- 
blem  variable,  this  rule  can  be  applied  to  any  problem  represented  by  a  frame  which  is  a 
child  of  the  class  frame  OPERATING  PROBLEMS.  This  action  is  controlled  by  the  pre¬ 
mise  "(?Problem  is  in  class  operating  problems)." 

Program  Control 

The  Sludgecadet  program  control  triggers  several  capabilities:  (1)  installing  the 
program  at  specific  WWTPs,  (2)  inputting  operating  and  plant  data,  (3)  reporting  data  and 
program  results,  and  (4)  diagnosing  operating  problems  and  recommending  remedial  ac¬ 
tion.  The  program  control  is  implemented  with  LISP  and  is  activated  with  KEE  active- 
image  Method  Actuators. 

Problem-Solving  by  Reasoning 

Diagnosing  problems  in  WWTPs  is  much  more  complex  than  simply  diagnosing  a  par¬ 
ticular  solution  to  a  specific  operating  problem.  An  experienced  operator  can  review 
problems  experienced  in  the  past  and  try  to  solve  a  new  problem  by  looking  for  similari¬ 
ties  or  associations  with  past  difficulties.  For  optimal  effectiveness,  an  experienced 
operator  should  first  see  if  a  problem  is  really  an  operating  problem  or  if  it  is  due  to 
some  other  factor.-  ’-  One  of  the  first  steps  in  problem  diagnosis  is  to  relate  similarities 
about  the  current  problem  to  those  in  the  past  and  ascertain  if  the  current  problem  may 
be  caused  by  something  over  which  the  operator  has  no  control. 

Reasoning  is  implemented  in  the  preliminary  analysis  phase  of  diagnosing  a  problem 
in  the  Sludgecadet  system.  In  the  current  version,  preliminary  analysis  consists  of  a  rule 
(e.g.,  the  Primary  Clarifier  Problem  Rule)  with  a  forward-chaining  strategy  that  asserts 
a  hypothetical  diagnosis  if  the  problem  is  related  to  operation  of  the  primary  clarifier 
and  a  procedure  (written  in  LISP)  that  creates  a  frame  for  a  new  problem.  A  problem 
frame's  attributes  include  the  date  the  problem  was  noticed,  a  diagnosis  if  one  was  made, 
action  taken  to  remedy  the  problem,  and  the  location  of  the  problem.  This  configuration 
allowed  successful  testing  of  the  feasibility  for  creating  a  database  of  problems  and  for 
identifying  operating  problems. 

The  second  phase  of  diagnosis  uses  the  problem's  hypothetical  solution  from  the 
preliminary  analysis  as  a  goal  in  a  backward-chaining  inference  exercise.  Since  this 
exercise  makes  use  of  more  than  one  rule,  the  inference  engine  "chains"  the  rule  by 
matching  similar  conclusions  from  one  rule  to  the  premises  of  another  rule  to  form  a  rule 
graph.  As  the  program  chains  from  the  goal  to  each  supporting  fact,  the  Sludgecadet 
system  first  checks  if  the  fact  is  available  in  the  KB;  if  not,  then  the  user  is  queried.  If  a 
diagnosis  is  made,  the  results,  which  are  displayed  by  Active  Images,  include  the 
diagnosis  of  the  problem,  the  primary  cause  or  reason  for  the  problem,  and  the  rec¬ 
ommended  remedial  action. 


2 1  U.S.  Environmental  Protection  Agency  (USEPA),  Handbook:  Improving  POTW  Per¬ 
formance  Using  the  Composite  Correction  Program  Approach,  EPA  625/6-84-008 
(October  1984). 
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User-Oriented  Interface  and  Delivery  Feasibility 

The  Sludgecadet  interface  was  designed  to  be  simple  to  use  and  as  self-explanatory 
as  possible  to  facilitate  use  by  a  novice  operator.  The  developers  took  full  advantage  of 
the  graphics  features  of  KEE  by  using  cursor-activated  menus  and  data  input  windows 
whenever  possible.  One  of  the  goals  of  this  kind  of  interface  is  to  minimize  the  amount 
of  time  the  operator  wouid  have  to  spend  typing  in  data  ana  commands. 

The  interface  as  seen  by  the  user,  not  the  developer,  consists  of  two  panels: 
Sludgecadet  control  and  plant/operating  information  (Figure  6).  Program  control  is 
activated  by  using  the  cursor  to  select  one  of  the  rectangles  labeled  INITIALIZE,  IDENT¬ 
IFY.  A. PROBLEM,  or  DIAGNOSE. A. PROBLEM.  The  results  of  and  explanation  for  the 
diagnostic  process  are  displayed  by  the  rectangles  entitled  Solution,  Primary  Cause, 
Diagnosis,  Probable  Cause,  and  Unit  Process  Location.  The  operating  data  interface  pro¬ 
vides  examples  of  active  images  that  are  used  for  input  as  well  as  output.  For  example, 
the  rectangle  entitled  "Actual  sludge  pumping  rate"  contains  a  number  that  can  be 
changed  by  superimposing  it  with  the  cursor  and  using  the  up-arrow  key  to  increase  it  or 
the  down-arrow  key  to  decrease  it. 


A  Development  Strategy  for  Sludgecadet  Enhancements 

A  logical  strategy  for  extending  the  Sludgecadet  system  is  to  add  knowledge  for 
operating  problems  other  than  the  TSS  exercise  discussed  above.  An  ideal  production 
version  of  Sludgecadet  would  be  able  to  diagnose  all  possible  problems  for  the  category 
of  WWTPs  with  trickling  filters  for  secondary  treatment  ana  with  anaerobic  digesters  for 
sludge  treatment.  The  next  stage  in  developing  Sludgecadet  would  focus  on  identifying 
representative  operating  problems  to  accommodate  typical,  but  not  necessarily  com¬ 
plete,  examples  of  what  might  actually  occur.  Although  specific  problem  examples  were 
not  identified  for  this  study,  the  following  categories  of  problems  would  be  considered: 

•  Biological  processes 

•  Physicochemical  processes 

•  Interaction  of  one  failure  with  others  in  the  plant 

•  Abnormal  data  trends 

•  Environmental  or  external  problems. 

Program  expansion  to  the  following  areas  is  conceivable: 

«  Operators'  training 

•  Minimization  of  energy  and  chemical  costs 

•  Plant  operation  and  laboratory  records  management 

•  Compliance  in  reporting  requirements 

•  Preventive  and  scheduled  maintenance 

•  Planning,  scheduling,  and  budgeting. 
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4  THE  PROOF-OF-CONCEPT  SYSTEM:  DISCUSSION 


Like  any  other  software,  the  pilot  Sludgecadet  system  should  be  evaluated  in  terms 
of  both  long-  and  near-term  benefits  and  costs.  Benefits  would  materialize  in  improved 
WWTP  performance  and  increased  productivity  for  the  system's  user.  Costs  would  accrue 
with  system  development,  software/hardware  purchases  and  maintenance,  and  user  train¬ 
ing.  Unlike  other  software,  expert  system  development  has  additional  benefits  and  costs 
associated  with  acquiring  and  encoding  expertise.  These  include  the  costs  for  identifica¬ 
tion  of  domain  experts,  formalization  of  an  expert's  problem-solving  knowledge,  and 
design  of  the  expert  system's  explanation  facilities.  This  chapter  assesses  the  advantages 
and  disadvantages  to  the  Army  associated  with  developing  and  using  a  WWTP  O&.M  sys¬ 
tem  like  Sludgecadet  in  terms  of  long-range  impacts,  near-term  impacts  of  this  work, 
and  any  immediate  extensions. 


Long-Term  Impacts 

improved  Plant  Performance 

The  Sludgecadet  system  was  intended  to  improve  the  performance  of  WWTPs  by 
giving  plant  operators  access  to  an  innovative  problem-solving  tool  and  by  contributing  to 
their  productivity.  The  most  immediate  benefit  of  Sludgecadet  would  come  from  assis¬ 
tance  in  diagnosing  plant  operating  problems  and  recommending  remedial  actions.  The 
system  would  make  the  problem-solving  knowledge  of  the  source  experts  available  to  the 
novice  operator.  In  addition,  the  system  would  provide  a  database  for  storing  and  quickly 
assessing  plant  and  operating  information.  Sludgecadet  was  not  intended  to  replace  an 
operator,  rather,  it  provides  operating  expertise  that  is  not  available  in  standard  manuals 
and  combines  that  knowledge  with  database  and  computational  facilities  to  assist  opera¬ 
tors. 

Operator  Training 

A  principle  feature  of  expert  system  architecture  is  separation  of  the  KB  (i.e., 
facts,  rules,  procedures)  from  the  system’s  control  mechanism  or  "inference  engine."  By 
separating  the  knowledge  from  control,  the  components  of  the  KB  become  accessible  for 
explanation  of  reasoning  and  for  user  tutoring.  GUIDON  is  one  example  of  a  commercial 
expert  system  designed  expressly  for  detailed  explanation  and  user  training.22  The 
GUIDON  expert  system  is  founded  on  MYCIN,  an  expert  system  that  diagnoses  microbial 
blood  infections  and  recommends  treatment.  GUIDON  combines  the  expertise  contained 
in  MYCIN  with  technology  from  areas  of  intelligent  computer-aided  instruction,  such  as 
dialog  structuring,  generating  teaching  material,  constructing  and  verifying  a  model  of 
the  student's  knowledge,  and  explaining  expert  reasoning.  During  tutorial  sessions,  the 
user  interacts  with  GUIDON  in  case  study  dialogs  in  which  GUIDON  has  access  to  the 
correct  problem  solution.  GUIDON’s  purpose  is  to  broaden  the  student's  knowledge  by 
pointing  out  inappropriate  lines  of  reasoning  and  suggesting  approaches  that  the  student 
did  not  consider. 

In  the  longterm,  the  Sludgecadet  system  could  be  used  as  a  foundation  for  a  tutorial 
system  similar  to  GUIDON.  The  diagnostic  rules,  facts,  and  procedures  specific  to  the 
domain  of  WWTP  operations  would  be  augmented  with  the  appropriate  intelligent 


22B.  Buchanan  and  E.  Shortliffe. 
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computer-aided  instruction  technology.  It  is  important  to  remember  that  systems  like 
Sliidgccndct  arc  only  computer  programs  and  arc  not  meant  to  replace  an  operator  certi¬ 
fication  and  training  program. 

Costs  Associated  With  System  Development  and  Deployment 

Long-term  costs  associated  with  developing  and  deploying  a  system  like  Sludge- 
cadet  would  involve  activities  for  system  enhancement,  system  maintenance,  and  user 
support.  These  costs  are  incurred  as  soon  as  a  system  is  placed  in  the  field  and  made 
available  to  users. 

To  effectively  promote  a  new  software  package,  it  is  necessary  to  educate  poten¬ 
tial  users  about  the  capabilities  and  benefits  of  the  system.  Users  will  require  formal 
training  through  short  courses,  tutorial  videos,  and/or  manuals.  In  addition,  at  least  one 
person  should  be  available  to  answer  questions  about  the  system's  operation  and  provide 
general  user  support. 

The  expansion  of  Sludgecadet  into  a  software  package  for  training  would  involve 
separate  long-term  costs.  These  costs  primarily  relate  to  software  development  to  pro¬ 
duce  intelligent  computer-aided  technology.  An  intelligent  training  system  would  not  re¬ 
quire  new  hardware  or  domain-specific  software. 

A  continuing  long-term  cost  would  come  from  personnel  requirements  for  software 
maintenance.  All  software  systems  eventually  require  maintenance.  In-house  personnel 
would  have  to  be  trained  in  the  technology  required  for  program  maintenance  or  contrac¬ 
tors  would  have  to  be  used. 

Another  issue  related  to  maintenance  is  that  of  system  enhancements.  Even  though 
well  designed  and  implemented  expert  systems  can  readily  accommodate  enhancements, 
there  are  still  costs  associated  with  evaluating  and  implementing  them.  Some  enhance¬ 
ments  are  relatively  trivial  to  add;  others  require  extensive  efforts  ir  design  nnd  imple¬ 
mentation.  Experts,  users,  and  software  specialists  would  need  to  evaluate  the  recom¬ 
mended  enhancements  and  decide  if  they  are  valuable  enough  to  be  implemented.  Once 
again,  the  issue  would  arise  as  to  wh.  her  in-house  personnel  or  contractors  should  be  re¬ 
sponsible  for  this  implementation. 

A  striking  characteristic  of  the  current  commercial  expert  systems  software  is  its 
rapid  state  of  flux  in  both  technical  capabilities  and  purchase  price.  The  major  compa¬ 
nies  in  the  AI  software  field  produce  technical  and  efficiency  enhancements  on  a  regular 
basis.  In  addition  to  significant  improvements  in  software  capabilities  and  reductions  in 
cost,  the  AI  hardware  market  is  expected  to  see  major  changes  in  the  next  few  years. 
Expert  systems  development  hardware  is  currently  shifting  from  a  specialized  LISP  work¬ 
station  development  environment,  in  which  each  brand  of  workstation  employs  its  own 
version  of  the  LISP  programming  language,  to  generalized  workstations  that  run  a  stand¬ 
ard  form  of  LISP  or  C  programming  language.  In  addition,  the  cost  of  these  workstations 
is  expected  to  decline  dramatically  as  more  and  more  companies  introduce  them  into  the 
market. 

An  even  greater  change  in  the  hardware  market  is  expected  with  technical 
advances  in  PC  architecture.  Over  the  next  few  years,  PCs  can  be  expected  to  grow  sig¬ 
nificantly  in  working  memory,  processing  speed,  and  graphics  capabilities.  Along  with 
these  changes,  it  is  projected  that  the  more  sophisticated  development  expert  systems 
packages,  such  as  KEE,  will  become  available  on  relatively  expensive  PCs. 
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Rpnefit/Cost  Analysis 

It  is  difficult  to  evaluate  the  costs  and  benefits  associated  with  developing  an 
expert  system  for  Army  WWTPs.  The  problem  is  twofold  in  that  (1)  little  work  has  been 
done  outside  the  Army  in  developing  expert  systems  for  process  control  in  WWTPs  and 
(2)  much  of  the  implementation  cost  of  an  expert  system  would  depend  on  the  level  of 
instrumentation  at  existing  treatment  facilities.  The  cost  of  AI  hardware  and  software 
for  any  given  facility,  once  the  basic  software/hardware  configuration  has  been  devel¬ 
oped,  would  be  small  compared  with  the  cost  of  plant  instrumentation.  With  the  recent 
advent  of  low-cost/high-power  computing  hardware  such  as  VAX  workstations,  the  hard¬ 
ware  cost  for  implementation  is  trivial  compared  with  the  annual  O&M  costs.  A  work¬ 
station  with  10  Mb  of  fast  memory  and  1  Gb  of  hard  disk  can  be  purchased  for  less  than 
$20K.  An  average  manyear  costs  approximately  $30K.  For  an  expert  system  with  work¬ 
stations,  it  may  cost  the  Army  between  $100K  and  $200K  to  obtain  an  Armywide  license 
from  the  manufacturer.  This,  too,  is  a  rather  small  investment  if  distributed  over  100  or 
more  treatment  facilities  Army-wide.  The  major  unknown  is  the  cost  required  to  develop 
an  expert  system  software  tailored  for  Army  WWTP  O&M.  Since  this  kind  of  software 
has  never  been  developed,  cost  data  for  full-scale  and  even  pilot-scale  applications  is  not 
available.  To  help  determine  this  cost,  the  major  treatment  trains  should  be  identified 
for  in-depth  investigation.  The  cost  of  installing  sensing  devices  to  measure  operational 
parameters  and  automatic  control  systems  to  actuate  the  plant  equipment  should  be 
considered. 

When  data  has  been  collected  and  reasonable  cost  estimates  made  for  implementing 
an  AI  system  for  O&M  at  Army  WWTPs,  the  savings  associated  with  the  implementation 
(in  terms  of  reduced  requirements  for  manpower,  energy,  chemicals,  etc.),  could  be  com¬ 
pared  with  the  cost  of  implementing  the  appropriate  control  systems  and  the  expert  sys¬ 
tem  development.  It  is  anticipated  that  many  of  these  numbers  would  fluctuate  during 
development  due  to  new  innovations  in  process  control  systems,  microcontrollers  for  unit 
operations,  and  advances  in  computer  hardware  and  software  techniques,  all  of  wnich 
woulo  .mpact  the  benefit/cost  relationship. 


Near-Term  Impacts 

Modular  and  Iterative  Development.  Approach 

Since  the  proposed  system  would  be  developed  in  an  iterative  fashion  using  a  modu¬ 
lar  structure,  the  current  version  would  always  be  functional  and  executable.  This  devel¬ 
opmental  approach  would  make  the  Sludgecadet  program  easy  to  expand  and  modify. 
Having  a  functional  version  available  at  all  times  would  permit  the  program  to  be  tested 
after  each  new  module  is  added.  An  iterative,  modular  developmental  approach  would 
match  the  requirements  of  the  kno  wledge  acquisition  cycle  described. 

Requirement  for  Continued  Software  Development 

To  continue  developing  the  Sludgecadet  system  past  the  initial  or  proof-of-concept 
stage,  resources  for  the  experts  and  knowledge  engineers  would  be  needed.  However, 
funds  for  such  activities  are  scarce.  Due  to  a  long  payback  period  in  comparison  to  other 
Operations  and  Maintenance,  Army  (OMA)  projects,  this  type  of  funding  is  given  low 
priority.  As  the  costs  for  such  systems  decline,  these  systems  may  become  more 
economically  attractive. 
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Hardware  and  Software  Requirements 

The  Sludgecadet  system  could  be  implemented  using  any  commercially  available 
expert  system  development  tool  with  the  following  features:  production  rules,  proced¬ 
ural  programming,  database,  and  facilities  for  creating  a  user-friendly  interface.  Com¬ 
mercial  expert  system  development  tools  fall  into  two  broad  categories:  those  for  PCs 
(e.g.,  IBM  PC  or  compatible)  and  those  for  LISP  machines  (e.g.,  all  Symbolics  LISP  mach¬ 
ines,  Xerox  D-Machines  1108  and  1186,  Texas  Instruments  Explorers)  or  general-purpose 
workstations  (e.g.,  Sun  3/75/110/140/160/260,  Vax  AI  workstations,  IBM  RT).  Both  work¬ 
stations  and  PCs  are  intended  as  single-user  machines. 

Expert  system  development  tools  available  for  PCs  have  the  advantages  of  lower 
purchase  prices  (around  $500  to  $10,000)  and  availability  for  the  PCs  at  most  Army 
installations.  In  any  case,  the  PC  hardware  has  a  modest  purchase  price  (around  $2000  to 
$12,000).  On  the  negative  side,  the  PC  software  is  quite  limited  in  representing  know¬ 
ledge,  providing  enough  memory  for  large  systems,  and  implementing  a  graphic  inter¬ 
face.  Expert  systems  development  tools  (or  "environments")  available  for  workstations 
provide  flexible  representation  facilities  and  do  not  limit  the  size  of  the  developing 
expert  system.  A  high-level  graphics  interface  allows  the  program  developer  to  quickly 
test  ideas  ("rapid  prototyping")  and  provides  high-level  graphics  for  the  user  interface. 
Unfortunately,  the  cost  of  these  systems  is  much  higher  (as  of  late  1987,  around  $40K  to 
$60K  for  the  software  and  $20K  to  $80K  for  the  hardware). 


Other  Issues 

To  implement  an  effective  AI  system  for  Army  WWTP  O&M,  the  following  items,  in 
addition  to  those  in  the  above  discussion,  would  have  to  be  considered: 

1.  Sensing  devices.  Proper  monitoring  and  control  of  WWTP  processes  would  not 
be  possible  without  reliable  sensing  devices.  Even  modern  technology  cannot  provide 
sensing  devices  that  are  simple  and  reliable  enough  to  measure  the  monitoring  and 
control  parameters  for  WWTP  operation.  Availability  and  reliability  of  sensing  devices 
must  be  evaluated  carefully  before  expert  systems  can  be  constructed. 

2.  Acceptance  of  AI  technology  by  the  WWTP  operators.  Some  operators  may 
have  a  negative  attitude  toward  expert  systems  or  computer  technology  in  general. 
Some  operators  may  regard  the  system  as  a  threat  to  their  job  security.  For  effective 
implementation  of  the  expert  system,  these  operators  would  have  to  be  convinced  that 
the  expert  system  is  a  too:  to  improve  their  plant's  operation. 

3.  Simplicity.  It  is  important  to  make  the  expert  system's  operation  as  simple  as 
possible.  Too  many  unnecessary  features  will  only  confuse  the  operators  and  reduce  the 
efficiency. 

4.  Size  and  number  of  WWTPs.  As  the  WWTP  size  increases,  the  application  of  AI 
will  be  more  cost-effective.  Although  no  attempt  was  made  to  determine  a  cutoff  limit 
for  economical  plant  size  in  this  study,  this  factor  must  be  evaluated  to  determine  if  the 
expert  system  implementation  would  be  economical.  Workstation  connection  with  all 
Army  WWTPs  or  a  group  of  WWTPs  also  must  be  evaluated. 

5.  Extent  of  AI  application.  Before  the  expert  system  is  designed,  the  extent  that 
the  expert  system  will  be  used  must  be  determined.  For  example,  the  expert  system  may 
be  used  only  for  troubleshooting,  or  for  plant  operation  and  record  management,  etc. 


6.  WWTP  automation.  WWTPs  can  be  automated  as  long  as  this  change  will  be 
cost-effective.  When  a  WWTP  is  being  automated,  the  future  potential  use  of  an  expert 
system  should  be  considered. 
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5  CONCLUSIONS  AND  RECOMMENDATIONS 


This  study  has  explored  opportunities  for  the  Army  to  exploit  recent  advances  in  AI 
technology  for  improving  O&M  at  its  WWTPs.  Based  on  findings  from  a  proof-of-concept 
exercise  performed  in  this  study,  Al/ES  has  potential  application  to  the  WWTP  industry; 
however,  there  are  also  limitations.  WWTP  processes  involve  many  parameters  that  must 
be  controlled  and  monitored  continuously,  often  within  very  strict  limits.  Current 
sensors  and  software  based  on  AI  are  neither  developed  enough  nor  economically 
justifiable  for  immediate  use  in  Army  WWTPs.  However,  with  the  rapid  growth  in  AI 
technical  capability  and  projected  lower  cost  in  the  future,  this  situation  can  be  expected 
to  change,  possibly  over  a  very  short  time  period. 

The  state  of  the  art  in  AI/ES  technology  has  been  reviewed  to  provide  a  general 
orientation  for  Army  personnel  who  may  be  required  to  evaluate  its  value  to  their  instal¬ 
lations. 

A  proof-of-concept  system  called  "Sludgecadet"  was  designed  and  tested  to  show 
the  feasibility  of  adapting  AI  technology  for  O&M  support  at  WWTPs.  Although  further 
development  of  this  system  would  be  impractical  at  this  time,  the  proof-of-concept 
exercise  has  established  that  AI/ES  could  have  a  role  in  future  automation  of  Army 
WWTPs.  It  should  be  noted  that  Sludgecadet's  feasibility  tests  were  limited  to  a  very 
small  segment  of  the  WWTP  process. 

The  expert  system  may  prove  to  be  an  innovative  tool  for  enhancing  and  extending 
the  Army's  limited  personnel  and  budgetary  resources  supporting  O&M  at  WWTPs.  How¬ 
ever,  since  cost  reduction  and  improvement  of  WWTP  performance  would  be  the  major 
reasons  for  using  this  technology,  it  does  not  appear  feasible  at  present.  AI/ES 
development  costs  for  Army  WWTP  O&M  are  currently  too  expensive  and  the  AI/ES 
technology  has  not  fully  demonstrated  the  potential  for  handling  the  complex  treatment 
process.  For  these  reasons,  it  is  recommended  that  the  Army  postpone  research  and 
development  on  such  systems  until  the  AI/ES  technology  has  evolved  further  and  becomes 
affordable.  In  addition,  it  is  recommended  that  any  installations  considering  purchase  of 
AI/ES-based  devices  perform  a  cost-effectiveness  study  to  determine  if  an  alternative 
technology  would  be  indicated. 
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